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ABSTRACT 


With  the  rapidly  falling  cost  of  computer  hardware 
continuing  to  drive  software  expenses  up,  attention  has 
turned  to  ways  to  effect  savings.  One  "'approach  that  shows 
particular  promise  is  rapid  prototyping.  Rapid  prototyping 
is  the  use  of  executable  models  of  a  software  system  to  firm 
up  the  requirements  before  a  significant  amount  of  time  and 
effort  has  been  invested  in  implementation.  The  computer- 
aided  prototyping  system  (CAPS)  is  a  rapid  prototyping 
system  that  automates  many  of  the  manual  processes  of 
prototyping,  thus  allowing  for  quicker  prototype 
construction  and  even  further  cost  savings. 

Within  CAPS  there  exists  an  execution  support  system. 
The  purpose  of  the  execution  support  system  is  to  take  the 
description  of  a  prototype  written  in  the  prototyping 
language  PSDL  and  to  convert  this  into  an  executable 
prototype  which  can  then  be  shown  to  the  user.  Previous 
research  resulted  in  separate  implementations  for  the 
components  of  the  execution  support  system,  but  these 
components  were  never  integrated  into  a  functioning  system. 


'3'3d&Mi 


It  is  the  development  of  this  tool  which  is  the  subject  of 
this  thesis. 
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I.  INTRODUCTION 


As  the  cost  of  computer  hardware  continues  to  decline, 
total  software  costs  continue  to  grow  rapidly  as  v  uncover 
more  and  more  problem  domains  that  demand  an  automated 
solution.  In  the  early  1970s,  total  software  costs  for  the 
Department  of  Defense  exceeded  $3  billion;  it  is  predicted 
that  in  1990  total  software  costs  for  embedded  computer 
systems  alone  will  exceed  $32  billion  [Ref.  l:p.  8]. 
According  to  one  economic  study,  costs  related  to  software 
accounted  for  about  2%  of  the  U.S.  gross  national  product  in 
1980,  or  about  $40  billion  [Ref.  2].  According  to  a  more 
recent  estimate,  software  related  expenses  had  risen  to 
about  5%  of  the  U.S.  GNP  in  1986,  or  about  $228  billion 
[Ref.  3]. 

As  the  rapidly  falling  cost  of  computer  hardware 
continues  to  drive  software  costs  up,  where  can  savings  be 
effected?  One  area  where  significant  savings  can  probably 
be  realized  is  in  the  area  of  software  maintenance. 
Software  maintenance  is  defined  as  the  changes  that  are  made 
to  an  existing  software  system.  Reports  vary  on  the  actual 
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figures,  but  its  estimated  that  industry  spends  from  40%  to 
75%  of  its  total  hardware  and  software  monies  on  software 
maintenance  [Ref.  4].  But  why  are  software  systems  changed? 
Software  systems  are  changed  for  the  following  reasons: 

New  situations 

Changes  in  the  environment  of  the  system  have  introduced 
new  requirements.  Examples  of  such  changes  are  new 
external  systems,  new  policies,  new  technologies,  and 
new  competitive  pressures. 

User  education 

Customer  requirements  have  changed  because  experience 
with  the  current  version  of  the  system  has  changed  their 
perception  of  how  computers  can  be  used  to  solve  their 
problems. 

Phased  delivery 

A  partial  implementation  has  been  delivered  because  the 
customer  cannot  wait  until  a  complete  implementation  is 
available. 

Requirements  errors 

The  developers  have  incorrectly  understood  the 
requirements  and  have  produced  a  system  that  does  not 
meet  user  needs. 

Implementation  errors 

A  faulty  design  or  implementation  does  not  correspond  to 
the  specification.  [Ref.  J:p.  2-3] 

One  approach  that  can  help  reduce  maintenance  costs  is 
rapid  prototyping.  A  prototype  is  an  executable  model  or 
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pilot  version  of  the  intended  software  system.  A  prototype 
is  usually  a  partial  representation  of  the  intended  system, 
used  as  an  aid  in  requirements  analysis  rather  than  as 
production  software.  The  rapid  construction  activity 
leading  to  such  a  prototype  is  called  rapid  prototyping. 
Prototypes  can  help  customers  visualize  and  test 
consequences  of  their  requirements,  thus  allowing  the 
requirements  to  be  stabilized  before  a  significant  amount  of 
time  and  effort  has  been  invested  in  implementation.  [Ref. 
6] 

The  traditional  software  life  cycle  consists  of  a  series 
of  phases  which  yield  runnable  software  only  late  in  the 
process.  One  view  of  the  traditional  life  cycle  is 
illustrated  in  Fig.  1.  A  major  problem  with  the  traditional 
approach  is  that  there  is  no  guarantee  that  the  resulting 
product  will  meet  the  customer's  needs.  Often  users  will  be 
able  to  indicate  the  true  requirements  only  by  observing  the 
operation  of  the  system,  and  the  traditional  life  cycle 
yields  executable  programs  late  in  the  process,  when  too 
much  money  has  already  been  spent.  [Ref.  5:p.  5-6] 
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Fig.  1  Traditional  Software  Life  Cycle 


This  problem  is  even  more  exacerbated  in  the  case  of  hard 
real-time  or  embedded  systems,  where  the  potential  for 
inconsistencies  is  greater.  One  of  the  major  differences 
between  a  real-time  computer  system  and  a  conventional 
system  is  the  required  precision  and  accuracy  of  the 
application  software.  The  response  time  of  each  individual 
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operation  may  be  a  significant  aspect  of  the  associated 
requirements,  especially  for  operations  whose  purpose  is  to 
maintain  the  state  of  some  external  system  within  a 
specified  region,  as  is  common  in  these  types  of  systems. 
These  response  times,  or  deadlines,  must  be  met  or  the 
system  will  fail  to  function,  possibly  with  catastrophic 
consequences.  These  requirements,  which  will  often  exceed 
the  intellectual  capacity  of  a  single  software  engineer,  can 
be  very  difficult  to  determine.  [Ref.  5:p.  6-7] 

Current  research  suggests  a  revised  software  development 
life  cycle  based  on  rapid  prototyping.  This  prototyping 
life  cycle  is  an  alternative  to  the  traditional  life  cycle 
which  has  been  proposed  to  alleviate  problems  stemming  from 
incorrect  requirements,  especially  when  designing  hard  real¬ 
time  or  embedded  systems.  As  a  software  development 
methodology,  rapid  prototyping  provides  the  user  and 
designer  with  a  fast,  efficient  and  easy-to-use  stepwise 
process.  When  utilized  during  the  early  stages  of  the 
development  life  cycle,  rapid  prototyping  allows  validation 
of  the  requirements,  specifications  and  initial  design 
before  valuable  time  and  effort  are  expended  on 
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implementation  software.  Fig.  2  graphically  depicts  this 


Fig.  2  Rapid  Prototyping  Loop 


methodology  as  a  feedback  loop.  Rapid  prototyping  is  an 
iterative  process  that  starts  out  with  the  user  defining  the 
requirements  for  the  critical  aspects  of  the  envisioned 
system.  Based  on  these  requirements,  the  designer  then 
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constructs  a  model  or  prototype  of  the  system  in  a  high- 
level,  prototype  description  language  and  examines  the 
execution  of  this  prototype  together  with  the  user.  If  the 
prototype  fails  to  execute  properly,  the  user  then  redefines 
the  requirements  and  the  prototype  is  modified  accordingly. 
This  process  continues  until  the  user  determines  that  the 
prototype  successfully  meets  the  critical  aspects  of  the 
envisioned  system.  Following  this  validation,  the  designer 
uses  the  validated  requirements  as  a  basis  for  the  design  of 
the  production  software.  [Ref.  5:p.  7-9] 

While  rapid  prototyping  has  been  found  to  be  an  effective 
technique  for  clarifying  requirements  and  eliminating  a 
large  amount  of  wasted  effort  currently  spent  on  developing 
software  to  meet  incorrect  or  inappropriate  requirements, 
the  addition  of  computer  aid  would  make  rapid  prototyping 
even  more  beneficial.  The  computer-aided  prototyping  system 
(CAPS)  is  a  prototyping  system  which  provides  this 
capability.  Designed  to  operate  on  the  prototyping  language 
PSDL  (Prototype  System  Description  Language) ,  CAPS  provides 
the  designer  with  an  integrated  set  of  tools  to  support 
prototyping  of  complex  software  systems  which  may  include 
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hard  real-time  constraints  [Ref.  5:p.  9].  These  tools 
include  an  execution  support  system,  a  rewrite  system,  a 
syntax-directed  editor  with  graphics  capabilities,  a 
software  base,  a  design  database,  and  a  design-management 
system  [Ref.  7:p.  66].  It  is  the  integration  of  the 
execution  support  system  which  is  the  focus  of  this  thesis. 

The  prototyping  language  PSDL,  along  with  the  prototyping 
method  are  examined  in  Chapter  II.  An  overview  of  CAPS  is 
given  in  Chapter  III.  Integration  of  the  execution  support 
system  is  discussed  in  Chapter  IV.  A  complete  prototype 
example  is  provided  in  Chapter  V.  Conclusions  are  presented 


in  Chapter  VI. 


II.  LANGUAGE  AND  METHOD 


A.  LANGUAGE 

A  good  language  for  expressing  design  thoughts  in  terms 
of  a  precise  model  is  important  for  rapid  prototyping.  It 
is  impossible  to  do  a  good  design  without  a  language 
designed  especially  for  this  purpose.  A  powerful,  easy-to- 
use,  and  portable  prototype-description  language  is  a 
critical  part  of  a  computer-aided  prototyping  system.  Such 
a  language  is  needed  before  the  tools  in  the  system  can  be 
built.  [Ref.  7:p.  68] 

PSDL  was  designed  together  with  the  prototyping  method  to 
ensure  the  most  efficient  use  of  the  language.  It  serves  as 
an  executable  prototyping  language  at  a  specification  or 
design  level  and  has  special  features  for  real-time  system 

design.  [Ref.  7:p.  68] 

1.  The  PSDL  Computational  Model 

The  PSDL  language  is  based  on  a  computational  model 
which  treats  software  systems  as  networks  of  operators 
communicating  via  data  streams.  The  computational  model  is 
an  augmented  directed  graph 


G=(V,E,T(v) ,C(v) ) 


where  V  is  the  set  of  vertices,  E  is  the  set  of  edges,  T(v) 
is  the  set  of  timing  constraints  for  each  vertex  v,  and  C(v) 
is  the  set  of  control  constraints  for  each  vertex  v.  Each 
vertex  is  an  operator  and  each  edge  is  a  data  path.  Each  of 
the  four  components  of  the  graph  are  described  in  more 
detail  below.  The  semantics  of  a  PSDL  system  description  is 
determined  by  the  associated  augmented  graph  and  the 
semantics  of  the  operators  appearing  in  the  diagram.  [Ref. 

8 :p.  2] 

a.  Operators 

All  PSDL  operators  are  either  FUNCTIONS  or  STATE 
MACHINES.  When  an  operator  fires,  it  reads  one  data  value 
from  each  of  its  input  streams,  and  writes  at  most  one  data 
value  on  each  of  its  output  streams.  The  output  objects 
produced  when  a  function  fires  depend  only  on  the  current 
input  values.  The  output  values  produced  when  a  state 
machine  fires  depend  only  on  the  current  input  values  and 
the  current  values  of  a  finite  number  of  internal  STATE 
VARIABLES.  [Ref.  6:p.  1411-1412] 

Each  operator  is  either  ATOMIC  or  COMPOSITE.  Atomic 
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operators  are  operators  which  cannot  be  decomposed  any 
further.  Composite  operators  are  operators  which  have 
realizations  as  data  and  control  flow  networks  of  lower 
level  operators.  A  composite  operator  whose  network 
contains  cycles  is  a  state  machine.  In  such  a  case,  one  of 
the  data  streams  in  each  cycle  is  designated  as  the  state 
variable  controlling  the  feedback  loop,  and  an  initial  value 
is  specified  for  it.  The  state  variables  serve  to  break  the 
circular  precedence  relationships  among  the  operators  which 
would  otherwise  be  implied.  In  the  example  shown  below, 
there  is  a  cycle  consisting  of  the  streams  S  and  Y.  The 
stream  X  is  the  only  input  to  the  network,  and  Z  is  the  only 
output.  [Ref.  6:p.  1412] 

In  PSDL,  S  would  be  designated  as  the  state  variable 
of  this  cycle  by  including  the  following 

states  S  initially  S-0 

in  the  specification  part  of  the  composite  operator.  S-0 
gives  the  initial  value  for  S.  [Ref.  6:p.  1412] 

b.  Data  Streams 

PSDL  operators  communicate  by  means  of  data  streams. 
A  data  stream  is  a  communciation  link  connecting  exactly  one 


producer  operator  to  exactly  one  consumer  operator.  In  Fig. 
3,  Y  is  a  data  stream  from  producer  op-1  to  consumer  op-2. 
Each  stream  carries  a  sequence  of  data  values  of  an  abstract 
data  type.  Streams  have  the  pipeline  property:  if  a  and  b 
are  two  data  values  in  data  stream  Y  and  the  data  value  a  is 
generated  by  op-1  before  value  b  is  generated  then  it  is 
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impossible  for  a  to  be  delivered  to  op-2  after  b  is 
delivered.  [Ref.  6:p.  1412] 

There  are  two  types  of  data  streams  in  PSDL-DATA 
FLOW  STREAMS  and  SAMPLED  STREAMS.  Dataflow  streams  are  used 
in  applications  where  the  values  in  the  stream  must  not  be 
lost  or  replicated,  while  sampled  streams  are  used  in 
applications  where  a  value  must  be  available  at  all  times 
and  values  can  be  replicated  without  affecting  their 
meaning.  A  dataflow  stream  can  be  thought  of  as  a  fifo 
queue  of  length  one,  while  a  sampled  stream  can  be  thought 
of  as  a  cell  capable  of  containing  just  one  value,  which  is 
updated  whenever  the  producer  generates  a  new  value.  [Ref. 
6:p.  1412] 

Dataflow  streams  guarantee  that  each  of  the  data 
values  written  into  the  stream  is  read  exactly  once. 
Computation  sequences  that  would  require  a  value  to  be 
written  into  a  full  queue  or  to  be  read  from  an  empty  queue 
result  in  an  error  message.  While  computation  sequences 
that  would  require  a  value  to  be  written  to  a  non-empty 
sampled  stream  are  valid,  attempts  to  read  from  an 
unitialized  sampled  stream  are  not,  and  will  result  in  an 
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error  message.  Thus,  this  type  of  error  can  be  avoided  by 
declaring  initial  values  for  sampled  streams.  [Ref.  8:p.  3- 
4] 

c.  Timing  Constraints 

Any  PSDL  operator  can  have  timing  constraints 
associated  with  it.  An  operator  is  time-critical  if  it  has 
at  least  one  timing  constraint  associated  with  it,  and  is 
non  time-critical  otherwise.  The  timing  constraints 
together  with  the  control  constraints  determine  when  the 
operator  can  be  fired,  and  when  it  must  be  fired.  There  are 
several  different  kinds  of  timing  constraints.  [Ref.  8:p.  4] 
The  most  basic  are  given  in  the  specification  part  of  a  PSDL 
module,  and  consist  of  the  MAXIMUM  EXECUTION  TIME,  the 
MAXIMUM  RESPONSE  TIME,  and  the  MINIMUM  CALLING  PERIOD  [Ref. 
6 :p.  1416]. 

Every  time-critical  operator  must  have  a  maximum 
execution  time  (MET)  to  allow  the  construction  of  a  static 
schedule.  The  MET  of  an  operator  is  an  upper  bound  on  the 
length  of  time  between  the  instant  when  a  module  begins 
execution  and  the  instant  when  it  completes,  called  the 
execution  interval  (El)  .  All  of  the  actions  that  may  be 
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required  to  fire  an  operator 


once  must  fit  into  the 


execution  interval.  These  actions  are  listed  below. 

(1)  Reading  values  from  input  data  streams. 

(2)  Evaluating  triggering  conditions. 

(3)  Calculating  output  values. 

(4)  Evaluating  output  guards. 

(5)  Writing  values  into  output  streams.  [Ref.  8:p.  4-5] 

Operators  triggered  by  temporal  events  are  periodic 
in  PSDL.  Every  periodic  operator  must  have  a  period 
(PERIOD)  and  may  have  a  deadline  (FINISH_WITHIN) .  These  two 
timing  constraints  partially  determine  the  set  of  scheduling 
intervals  (SI)  for  the  operator.  Each  periodic  operator 
must  be  fired  exactly  once  in  each  scheduling  interval,  and 
must  complete  execution  before  the  end  of  the  scheduling 
interval.  The  period  is  the  length  of  time  between  the 
start  of  any  scheduling  interval  and  the  start  of  the  next 
scheduling  interval.  The  deadline  is  the  length  of  each 
scheduling  interval.  The  starting  time  of  the  first 
scheduling  interval  for  each  operator  is  determined  by  the 
static  scheduler.  [Ref.  8:p.  5] 

The  relation  between  the  timing  constraints, 
scheduling  intervals,  and  execution  intervals  for  a  periodic 
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operator  is  illustrated  in  Fig.  4.  The  execution  intervals 
and  scheduling  intervals  in  the  diagram  are  indexed  by 
integers  in  the  order  of  their  occurrence.  Thus  SI[n] 
denotes  the  n-th  scheduling  interval  for  the  operator  and 
EI[n]  denotes  the  n-th  execution  interval  for  the  operator. 
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The  static  scheduler  takes  the  length  of  each  execution 
interval  to  be  equal  to  the  maximum  execution  time  to  allow 
for  worst  case  conditions.  If  a  time-critical  operator 
completes  before  the  end  of  the  execution  interval  reserved 
for  it  by  the  static  scheduler,  the  remaining  time  in  the 
execution  interval  is  used  by  the  dynamic  scheduler  for  the 
execution  of  a  non  time-critical  operator.  [Ref.  8:p.  5] 

Operators  triggered  by  the  arrival  of  new  data 
values  are  sporadic.  Timing  constraints  for  sporadic 
operators  are  optional.  Sporadic  operators  with  timing 
constraints  must  have  both  a  maximum  response  time  (MRT)  and 
a  minimum  calling  period  (MCP)  in  addition  to  a  MET.  The 
MRT  is  an  upper  bound  on  the  time  between  the  arrival  of  a 
new  data  value  and  the  time  when  the  last  value  is  put  into 
the  output  streams  of  the  operator  in  response  to  the 

W* 

arrival  of  the  new  data  value.  The  MCP  is  a  constraint  on 
the  environment  of  a  sporadic  operator,  consisting  of  a 
lower  bound  on  the  delay  between  the  arrival  of  one  set  of 
inputs  and  the  arrival  of  the  next  set.  The  relation  between 
these  quantities  is  illustrated  in  Fig.  5.  SI[n]  denotes 
the  n-th  scheduling  interval  for  the  consumer  operator, 
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which  is  sporadic  and  time-critical.  CEI[n]  denotes  the  n- 


th  execution  interval  for  the  consumer  operator,  and  PEI[n] 
denotes  the  n-th  execution  interval  for  the  producer 
operator,  which  is  assumed  here  to  be  time-critical  also. 
The  response  time  associated  with  a  consumer  operator  is 
measured  from  the  end  of  the  execution  interval  for  the 


calling  period 


PEI[n]  =  n-th  producer  execution  Interval 
CEI[n]  =  n-th  consumer  execution  Interval 
Sl[n]  =  n-th  scheduling  Interval 


Fig.  5  Timing  Constraints  for  a  Sporadic  Operator 


producer  operator  of  the  triggering  data  value  to  the  end  of 
the  execution  interval  for  the  consumer  operator  of  the 
triggering  data  value.  [Ref.  8:p.  6] 

Unlike  the  MET,  the  MRT  includes  a  scheduling  delay. 
The  MRT  gives  the  length  of  the  scheduling  interval.  The 
static  scheduler  may  not  be  able  to  use  the  entire 
scheduling  interval  if  the  producer  is  non  time-critical, 
because  the  ending  time  of  the  producer's  execution  interval 
is  not  known  to  the  static  scheduler  in  that  case.  [Ref. 
8 :p.  6] 

The  calling  period  of  an  operator  is  the  length  of 
time  between  the  end  of  the  execution  interval  for  the 
producer  of  the  triggering  data  value  and  the  end  of  the 
execution  interval  for  the  producer  of  the  next  triggering 
data  value.  The  calling  period  must  not  be  less  than  the 
MCP.  The  MCP  of  an  operator  constrains  the  behavior  of  the 
producers  of  the  triggering  data  values  rather  than 
constraining  the  behavior  of  the  operator  itself.  An  MCP 
constraint  is  needed  to  allow  the  realization  of  a  maximum 
response  time  constraint  with  a  fixed  amount  of 
computational  resources,  via  a  limit  on  the  frequency  with 
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which  new  data  can  arrive.  Violation  of  an  MCP  constraint 
should  result  in  a  warning  message.  [Ref.  8:p.  6-7] 
d.  Control  Constraints 

The  control  aspect  of  a  PSDL  operator  is  specified 
implicitly,  via  control  constraints.  Control  constraints 

are  used  for  the  following  purposes: 

(1)  Controlling  operator  execution. 

(2)  Controlling  output. 

(3)  Controlling  exceptions. 

(4)  Controlling  timers.  [Ref.  8:p.  7] 

Exceptions  are  discussed  in  Chapter  IV.  Readers  interested 
in  a  discussion  of  timers  can  refer  to  [Ref.  ll:pp.  18-20]. 

Control  constraints  controlling  operator  execution 
are  called  triggering  conditions.  The  forms  of  PSDL 
triggering  conditions  are  shown  in  Fig.  6.  A  triggering 
condition  has  two  parts,  the  trigger  and  the  guard,  both  of 
which  are  optional.  The  trigger  defines  the  conditions 
under  which  an  operator  can  be  fired.  The  keywords 
"TRIGGERED  BY  ALL"  indicate  the  operator  is  ready  to  fire 
whenever  new  data  values  have  arrived  on  all  of  the  input 
data  streams  named  in  the  id_list.  The  id_list  can  contain 
any  non-empty  subset  of  the  input  data  streams  for  the 
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operator.  [Ref.  8:p.  7]  This  kind  of  trigger  can  be  used  to 
ensure  that  the  output  of  the  operator  is  always  based  on 
fresh  data  for  all  of  the  inputs  in  the  list,  and  can  be 
used  to  synchronize  the  processing  of  corresponding  input 
values  from  a  number  of  input  streams  [Ref.  6:p.  1414].  The 
natural  dataflow  firing  rule  corresponds  to  a  “TRIGGERED  BY 
ALL"  triggering  condition  that  lists  all  of  the  input  data 
streams  of  the  operator.  [Ref.  8:p.  7-8] 

triggering_condition  = 

"OPERATOR"  id  "TRIGGERED"  ["BY"  trigger]  ["IF"  guard] 
trigger  =  "ALL"  id_list  |  "SOME"  id_list 

Fig.  6  PSDL  Triggering  Conditions 
The  keywords  "TRIGGERED  BY  SOME"  indicate  the 
operator  can  be  fired  if  there  is  a  new  data  value  on  at 
least  one  of  the  data  streams  named  in  the  id_list  [Ref. 
8:p.  8].  This  kind  of  trigger  can  be  used  to  keep  software 
estimates  of  sensor  data  up  to  date  [Ref.  6:p.  1414].  A 

null  trigger  means  that  the  operator  can  fire  at  any  time, 
whether  or  not  any  new  data  values  have  arrived.  Null 
triggers  are  most  useful  for  periodic  operators. 

The  triggering  conditions  of  the  operators 

implicitly  determine  the  types  of  the  data  streams.  A 
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stream  is  a  dataflow  stream  if  it  appears  in  a  "TRIGGERED  BY 
ALL"  constraint  of  the  consumer  operator  and  is  a  sampled 
stream  otherwise.  [Ref.  8:p.  8] 

The  second  part  of  the  triggering  condition  is  the 
guard,  a  boolean  expression  which  can  depend  only  on  the 
input  values  to  the  operator  and  locally  available  state 
information.  A  null  guard  is  always  true.  When  an  operator 
fires,  it  reads  one  data  value  from  each  of  its  input 
streams.  If  the  predicate  is  satisfied,  then  the  output 
values  of  the  operator  are  calculated,  otherwise  the  firing 
of  the  operator  terminates  immediately  without  producing  any 
output.  [Ref.  8 :p.  8] 

Constraints  for  controlling  output  are  based  on 
output  guards.  An  output  guard  is  a  boolean  expression  that 
can  depend  on  the  input  data  of  the  operator,  locally 
available  state  information,  and  the  calculated  output 
values.  A  null  output  guard  is  always  true.  [Ref.  8:p.  8] 
An  example  of  a  control  constraint  specifying  a  conditional 
output  is  shown  below. 

OPERATOR  t  OUTPUT  z  IF  1  <  z  AND  z  <  max 
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The  example  shows  an  operator  with  an  output  guard,  which 
depends  on  the  input  value  MAX  and  the  output  value  z  [Ref. 
6:p.  1415].  An  output  value  is  written  to  the  output  stream 
provided  that  the  output  guard  evaluates  to  true.  If  the 
output  guard  evaluates  to  false,  then  nothing  is  written 
into  the  stream.  [Ref.  8:p.  8] 

2 .  Abstractions 

Abstractions  are  an  important  means  for  controlling 
complexity,  which  is  especially  important  in  rapid 
prototyping  because  a  system  must  appear  to  be  simple  to  be 
built  or  analyzed  quickly.  PSDL  supports  three  kinds  of 
abstractions:  data  abstractions,  operator  abstractions,  and 

control  abstractions.  [Ref.  6:p.  1413] 

a.  Operator  Abstractions 

There  are  two  types  of  operator  abstractions: 
functional  abstractions  and  state  machine  abstractions. 
PSDL  supports  both  types.  A  PSDL  operator  consists  of  two 
parts:  a  SPECIFICATION  part  and  an  IMPLEMENTATION  part. 
The  specification  part  contains  attributes  describing  the 
form  of  the  interface,  the  timing  characteristics,  and 
descriptions  of  the  observable  behavior  of  the  operator. 
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The  attributes  both  specif iy  the  operator  and  form  the  basis 
for  retrievals  from  a  software  base.  The  set  of  attributes 
consists  of  GENERIC  PARAMETERS,  INPUT,  OUTPUT,  STATES, 
EXCEPTIONS,  and  TIMING  INFORMATION.  [Ref.  6:p.  1413] 

A  PSDL  operator  corresponds  to  a  state  machine 
abstraction  if  its  specification  part  contains  a  STATES 
declaration,  otherwise  it  corresponds  to  a  functional 
abstraction.  The  STATES  declaration  gives  the  types  of  the 
state  variables  and  also  their  initial  values.  [Ref.  6:p. 
1413] 

The  implementation  part  of  the  operator  signifies 
whether  it  is  atomic  or  composite.  Atomic  operators  have  a 
keyword  specif iying  the  underlying  programming  language, 
followed  by  the  name  of  the  module  implementing  the 
operator.  This  name  is  filled  in  as  the  result  of  a 

successful  retrieval  from  the  software  base,  or  is  supplied 
by  the  designer  in  cases  where  the  module  cannot  be 
constructed  from  reusable  components  and  must  be  coded 
manually.  [Ref.  6:p.  1413] 
b.  Data  Abstractions 

All  of  the  PSDL  data  types  are  immutable.  For 
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immutable  types  the  set  of  instances  and  the  properties  of 
each  instance  are  fixed.  All  PSDL  variables  are  local. 
Both  mutable  data  types  and  global  variables  can  lead  to 
coupling  problems  in  large  prototype  systems  and  thus  have 
been  excluded  from  PSDL.  [Ref.  6:p.  1413] 

The  PSDL  data  types  include  the  immutable  subset  of 
the  built-in  types  of  Ada,  user  defined  abstract  types,  the 
special  types  TIME  and  EXCEPTION,  and  the  types  that  can  be 
built  using  the  immutable  type  constructors  of  PSDL.  The 
PSDL  type  constructors  (see  Table  1)  were  chosen  to  provide 
powerful  data  modeling  facilities.  [Ref.  6:p.  1414] 


TABLE  1.  PSDL  TYPE  CONSTRUCTORS 


set [item:  type] 

sequence [ item:  type] 

map [ f r om :  type ,  t o : 

type] 

tuple [tag_l:  T_l,... 

,  tag_n : 

T_n] 

one_of [ tag_l :  T_1 , . . 

. ,  tag_n: 

T_n] 

relation [tag_l:  T_l, 

. . . ,  tag_ 

_n:  T_n] 

Finite  sets,  sequences,  and  mappings  correspond  to 


the  usual  mathematical  concepts.  Tuples  are  finite 
Cartesian  products,  with  operations  for  constructing  tuples 
and  for  extracting  components.  One_ofs  are  tagged  disjoint 
unions  of  a  finite  number  of  other  types,  with  operations 
for  constructing  one_of  values  with  a  given  tag 


(injections) ,  for  testing  whether  a  one_of  value  has  a  given 
tag  (domain  predicates) ,  and  for  extracting  the  data 
component  of  a  one_of  (projections) .  Relations  are  n-ary 
mathematical  relations,  with  operations  that  are  commonly 
used  in  relational  databases  (select,  project,  join,  union, 
set  difference,  etc.)*  [Ref.  6:p.  1414] 
c.  Control  Abstractions 

Enhanced  data  flow  diagrams,  augmented  by  control 
constraints  represent  the  control  abstractions  of  PSDL. 
Periodic  execution  is  supported  explicitly,  as  well  as 
concurrent  execution  in  certain  cases.  Order  of  execution 
is  determined  from  the  data  flow  relations  given  in  the 
enhanced  data  flow  diagrams,  based  on  the  rule  that  an 
operator  consuming  a  data  value  must  not  start  until  after 
the  operator  producing  the  data  value  has  completed.  This 
applies  to  periodic  operators  only  at  synchronization 
points,  which  occur  at  intervals  equal  to  the  least  common 
multiple  of  the  periods  of  the  two  operators. 

B.  THE  PROTOTYPING  METHOD 

The  PSDL  prototyping  method  is  a  decomposition  strategy 
which  results  in  a  hierarchically  structured  prototype.  The 
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prototyping  method  provides  a  strategy  for  filling  in  more 
details  at  any  level  of  the  prototype  design  and  helps  the 
designer  focus  on  the  critical  subsystems  that  must  be 
refined  to  resolve  the  problems  that  motivated  the  rapid 
prototyping  effort.  [Ref.  9:p.  26] 

Fig.  7  illustrates  the  major  steps  in  the  prototyping 
method.  The  designer  begins  by  entering  the  specifications 
of  the  intended  software  component.  A  rewrite  subsystem 
maps  the  specification  into  an  internal  abstract  form  that 
is  used  by  the  design-management  system  to  search  for  a 
reusable  component  to  implement  the  specification.  If  a 
reusable  component  is  found,  the  design-management  system 
retrieves  it;  if  it  finds  several  reusable  components  that 
meet  the  specification,  the  designer  must  choose  one. 
Otherwise,  the  specification  cannot  be  met  by  an  existing 
component  and  the  designer  should  decompose  the 
specification  into  simpler  specifications  or  create  a  hand- 
coded  implementation  if  the  component  is  so  simple  that 
decomposition  does  not  make  sense.  [Ref.  7:p.  67] 

When  a  specification  is  decomposed  into  a  network  of 
simpler  components,  the  required  interconnections  are 


27 


recorded  in  the  design  database  with  a  dataflow  diagram. 


This  helps  serve  as  design  documentation.  After  the 
designer  decomposes  the  specification  into  simpler 


Specifications 


▼ 


Implementation 

Fig.  7  The  Prototyping  Method 

specifications,  the  entire  prototyping  method  is  then 
applied  to  those  specifications.  [Ref.  7:p.  67] 
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III.  COMPUTER-AIDED  PROTOTYPING  8Y8TEM 


The  computer-aided  prototyping  system  (CAPS)  is  a  set  of 
software  tools  which  reduces  the  designer's  efforts  by 
automating  time-consuming  tasks  in  conventional  prototyping, 
such  as  turning  specifications  into  prototypes,  modifying 
prototypes,  and  searching  for  available  reusable  components 
[Ref.  7 :p.  67-68].  Designed  to  operate  on  the  prototyping 
language  PSDL,  CAPS  consists  of  a  syntax-directed  editor 
with  graphics  capabilities,  a  rewrite  system,  a  design- 
management  system,  a  software  base,  a  design  database,  and 
an  execution  support  system  [Ref.  7:p.  66].  Fig.  8  shows 
the  architecture  of  the  computer-aided  prototyping  system. 
Following  is  a  short  description  of  the  functions  of  each  of 
the  components  of  CAPS. 

A.  USER  INTERFACE 

The  user  interface  consists  of  a  syntax-directed  editor 
for  PSDL  and  a  graphics  tool  to  construct  and  display 
dataflow  diagrams.  The  syntax-directed  editor  expedites  the 
designer's  data  entry  at  a  terminal  by  eliminating  syntax 
errors,  automatically  supplying  keywords,  and  prompting 
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Design  Database 

- 1 

Software  Base  ! 

Fig.  8  CAPS  System  Architecture 

with  a  choice  of  legal  syntactic  alternatives  at  each  point. 
[Ref.  9 :p.  29] 

The  graphics  tool  provides  a  graphical  view  of  the 
enhanced  data  flow  diagram  in  the  PSDL  implementation  of  a 
composite  module.  It  helps  you  visualize  the  relationships 
between  the  components  of  a  decomposition  through  a  two- 
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dimensional  dataflow  diagram  and  provides  a  convenient  way 
to  enter  and  update  the  decomposition  information  in  the 
dataflow  diagram.  [Ref.  9:p.  29] 

B.  REWRITE  SYSTEM 

The  rewrite  system  translates  semantically  equivalent 
specifications  into  a  common  (normalized)  form  that  is  used 
by  the  design-management  system  to  search  for  components. 
Normalized  components  are  easier  to  retrieve  because  there 
are  fewer  keys  to  search  for  in  the  software  base.  This  is 
a  more  practical  approach  than  trying  to  generate  all 
variations  of  a  description  and  searching  the  software  base 
for  each  variation.  Table  2  shows  an  example  of  an  informal 
rewriting  system.  [Ref.  7:p.  69) 


TABLE  2. 

SAMPLE  REWRITE-SYSTEM  RULE  TABLE. 


Term 

Aliases 

update 

change,  modify,  refresh, 
replace,  substitute 

read 

fetch,  obtain,  input,  get, 
retrieve 

The  rewrite  system  would  replace  all  occurrences  of  the 
aliases  by  the  associated  basic  terms.  The  sentence  "Fetch 
the  order  from  the  transaction  file  and  modify  the 
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inventory"  would  be  rewritten  to  "Read  the  order  from  the 
transaction  file  and  update  the  inventory."  [Ref.  7:p.  69] 

C.  DESIGN-MANAGEMENT  SYSTEM 

The  design-management  system  is  responsible  for 
organizing,  retrieving,  and  instantiating  reusable 
components  from  the  software  base  and  for  managing  the 
versions,  refinements,  and  alternatives  of  the  prototypes  in 
the  design  database.  The  design-management  system  is 
essentially  a  database-management  system  that  can 
efficiently  manage  long  transactions,  data  describing 
complex  objects  (such  as  software  components) ,  the  iterative 
and  tentative  nature  of  the  design  process  that  leads  to 
versions,  refinements,  and  alternatives  of  the  design 
objects,  and  concurrent  design  operations  in  a  distributed 
computing  environment.  It  also  provides  special-purpose 
operations  to  compose  components,  and  a  browsing  capability 
similar  to  the  one  provided  by  the  Smalltalk  environment. 
[Ref.  7 :p.  69] 

D.  SOFTWARE  BASE 

The  software  base  consists  of  PSDL  descriptions  and  code 
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for  all  available  reusable  software  components. 


Each 


component  in  the  software  base  must  have  a  PSDL 
specification.  This  PSDL  specification  is  organized  as  a 
set  of  distinct  but  related  attributes.  The  design- 
management  system  provides  component  retrieval  based  on 
partial  matches  of  these  attributes.  The  software  base 
contains  a  relatively  complete  set  of  general-purpose 
components  to  perform  the  functions  common  to  many  systems, 
such  as  managing  displays,  sorting  and  searching,  parsing 
input  strings,  and  managing  look-up  tables.  [Ref.  9:p.  29] 

E.  DESIGN  DATABASE 

The  design  database  in  the  prototyping  environment 
contains  the  PSDL  prototype  descriptions  for  each  software 
development  project  using  CAPS.  This  design  history 
consists  of  the  relationship  between  each  version  of  the 
requirements  and  the  corresponding  versions  of  parts  of  the 
prototype.  This  information  is  useful  in  cases  where  parts 
of  the  requirements  are  returned  to  previous  configurations, 
because  it  enables  the  system  to  help  restore  the 
corresponding  parts  of  the  prototype  to  their  previous 
configurations.  The  design  database  will  support  retrievals 
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of  the  form 


-  given  a  requirement,  find  all  the  PSDL 
components  that  implement  it,  or 

-  given  a  PSDL  component,  find  all  the 
requirements  it  implements.  [Ref.  9:p.  29] 

F.  EXECUTION  SUPPORT  SYSTEM 

Within  the  CAPS  architecture  there  exists  an  execution 
support  system  which  allows  the  designer  to  execute  the 
prototype.  This  support  system  consists  of  three  major 
components:  a  translator,  a  static  scheduler,  and  a  dynamic 

scheduler.  The  translator  generates  code  binding  together 
the  reusable  components  extracted  from  the  software  base. 
Its  main  functions  are  to  implement  data  streams  and  control 
constraints.  The  static  scheduler  allocates  time  slots  for 
operators  with  real-time  constraints  before  execution 
begins.  If  the  allocation  succeeds,  all  operators  are 
guaranteed  to  meet  their  deadlines  even  with  worst-case 
execution  times.  The  dynamic  scheduler  invokes  operators 
without  real-time  constraints  in  the  time  slots  not  used  by 
the  operators  with  real-time  constraints  as  execution 
proceeds.  [Ref.  5:p.  16]  [Ref.  10:p.  15-16] 
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The  execution  support  system  is  covered  extensively  in 


the  remaining  chapters. 
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IV.  INTEGRATION  OF  THE  EXECUTION  SUPPORT  SYSTEM 


A.  OVERVIEW 

The  execution  support  system  as  conceptualized  by  this 
author  is  shown  in  Fig.  9.  It  consists  of  three  processes: 
the  translator,  the  static  scheduler  and  the  dynamic 
scheduler.  The  translator  takes  as  input  the  PSDL  source 
code  generated  by  the  designer  and  produces  DRIVER 
procedures,  contained  in  package  TL,  which  call  the  reusable 
components  in  package  SB.  The  static  scheduler  takes  as 
input  the  PSDL  source  code  and  produces  two  outputs:  the 
static  schedule  for  the  time-critical  operators  and  a  file 
called  non_crits  containing  the  names  of  the  non-time- 
critical  operators.  The  dynamic  scheduler  takes  as  input 
the  file  non_crits  and  uses  this  to  produce  an  Ada  task 
containing  procedure  calls  for  the  non-time-critical 
operators. 

The  user  interface  is  responsible  for  invoking  the 
translator,  static  scheduler  and  dynamic  scheduler.  The 
translator  and  the  static  scheduler  can  operate  in  parallel, 
however  the  dynamic  scheduler  must  wait  for  completion  of 
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the  static  scheduler  before  it  can  run. 


Once  the 


translator,  static  scheduler  and  dynamic  scheduler  have 
completed,  the  user  interface  takes  their  outputs  as  well  as 
the  packages:  PSDL_SYSTEM,  PSDL_EXCEPTIONS ,  SB,  Global_ 
Declarations,  DS_Debug_PKG,  TIMERS,  VSTRINGS ,  List_Single_ 


Fig.  9  Execution  Support  System 


Unbounded_Unmanaged  and  PRIORITY_DEFINITIONS  and  compiles 
and  links  them,  thus  forming  the  executable  prototype. 
Note,  the  latter  four  packages  are  the  ADDITIONAL  RUNTIME 
SUPPORT. 

Previous  research  resulted  in  separate  implementations 
for  the  translator  [Ref.  11],  static  scheduler  [Ref.  12] 
[Ref.  13]  [Ref.  14]  [Ref.  15],  and  dynamic  scheduler  [Ref. 
16].  These  individual  components  were  not  previously 
integrated  though  into  a  functioning  execution  support 
system  which  enables  the  execution  of  prototypes  written  in 
PSDL.  It  is  the  development  of  this  tool  that  is  the  focus 
of  this  thesis. 

B.  MODIFICATIONS  TO  THE  TRANSLATOR 

1.  Data  stream  Implementation 

Data  streams  are  the  means  by  which  PSDL  operators 
communicate.  A  data  stream  is  a  communication  link 
connecting  exactly  one  producer  operator  to  exactly  one 
consumer  operator.  Altizer  [Ref.  11 :p.  40]  describes  an 
implementation  for  data  streams  in  which  data  streams  are 
implemented  as  an  Ada  generic  package  containing  an  embedded 
task.  Inside  the  task  are  the  various  operations  necessary 
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to  support  data  triggers  and  data  stream  reads  and  writes. 
Four  separate  packages  are  provided  to  implement  the 
variations  of  data  streams.  All  of  these  packages  are  then 
grouped  into  a  package  called  PSDL_SYSTEM. 

While  Altizer's  handling  of  data  streams  was  found  to 
be  essentially  adequate,  several  modifications  were  made  to 
the  original  design.  Appendix  A  contains  the  new  version  of 
PSDL_SYSTEM. 

One  change  made  was  to  replace  the  literal  value  in  the 
pragma  PRIORITY  with  the  constant  BUFFER_PRIORITY .  The 
value  of  BUFFER_PRIORITY  is  declared  in  the  package 
PRI0RITY_DEFINITIGNS  along  with  the  values  of  the  constants 
STATIC_SCHEDULE_PRIORITY  and  DYNAMIC_SCHEDULE_PRIORITY .  The 
purpose  of  doing  this  is  to  consolidate  all  the  PRIORITY 
pragma  values  for  the  prototype  into  one  package,  so  that 
future  design  changes  and  enhancements  will  be  easier  to 
make. 

Another  change  made  to  the  original  design  was  to 
eliminate  the  record  type  DATA_STREAM_TOKEN .  DATA_ 
STREAM_TOKEN  was  determined  to  be  unnecessary  and  was 
replaced  instead  with  two  local  variables:  BUFFER  and  FRESH. 
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The  names  of  several  identifiers  in  PSDL_SYSTEM  were 
changed.  For  instance,  SAMPLED_STREAM  was  changed  to 
SAMPLED_BUFFER.  DATA_STREAM  was  changed  to  BUFFER.  GET  WCS 
changed  to  READ.  PUT  was  changed  to  WRITE,  etc.  This  was 
done  in  the  interest  of  improving  clarity. 

Finally,  probably  the  most  significant  change  made  was 
to  consolidate  the  generic  packages  SAMPLED_STATE_VAR  and 
DATAFLOW_STATE_VAR  into  one  package  STATE_VARIABLE .  Having 
both  SAMPLE D_STATE_VAR  and  DATAFLOW_STATE_VAR  was  found  to 
be  redundant. 

2.  Integration  of  Reusable  Components 

In  Chapter  II.  of  this  thesis,  a  short  description  is 
given  of  the  prototyping  method,  which  is  the  process  by 
which  a  PSDL  atomic  operator  specification  is  used  to 
extract  a  reusable  Ada  component  from  the  software  base. 
These  components,  which  represent  the  implementations  of  the 
atomic  operators,  are  critical  to  the  functioning  of  the 
prototype.  Yet,  up  until  Altizer  [Ref.  lisp*  38],  no 
provision  was  made  for  their  insertion  into  the  prototype. 

Altizer  proposed  that  when  a  reusable  module  is 
extracted  from  the  software  base,  that  it  be  inserted  into 
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the  PSDL  source  code  at  the  IMPLEMENTATION  statement.  Then, 
when  the  PSDL  source  code  is  processed  by  the  translator 
this  component  would  be  extracted  and  placed  in  the  TL 
package,  which  is  the  output  of  the  translator. 

This  approach,  though  it  seems  viable,  was  never 
actually  implemented  by  Altizer.  An  alternative  approach 
that  actually  was  implemented  during  the  course  of  this 
thesis,  makes  use  of  the  Ada  with  and  use  clauses.  In  this 
approach  all  components  extracted  from  the  software  base  are 
assembled  into  a  package  called  SB  which  is  placed  into  a 
file  called  sb.a.  The  output  of  the  translator,  package  TL, 
consists  then  of  DRIVER  procedures  which  call  these 
components.  Visibility  to  package  SB  is  provided  via  the 

Ada  with  and  use  clauses.  This  is  illustrated  in  Fig.  10. 

3 .  Exception  Handling 

PSDL  exceptions  are  described  by  Luqi  in  [Ref.  17]  as 
special  data  types  that  may  be  written  to  any  data  stream 
regardless  of  the  stream's  normal  data  type.  When  a  PSDL 
exception  is  raised  in  an  operator  it  is  immediately  output 
onto  all  of  the  operator's  output  data  streams.  All 
operators  immediately  downstream  from  this  operator  receive 
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the  exception  on  one  or  more  of  their  input  streams  and  are 
then  responsible  for  its  handling. 

with  TEXTJO;  use  TEXT  JO; 

with  PSDL_EXCEPT IONS;  use  PSO ^EXCEPTIONS ; 

package  SB  is 

end  SB; 

package  body  SB  is 

reusable  Ada  components 

end  SB; 
package  TL  is 

end  TL; 

With  PSDL_SYSTEM;  use  PSDL_SYSTEM; 
with  PSDL_EXCEPTIONS;  use  PSDLJXCEPTIONS; 
with  SB;  use  SB; 
package  body  TL  is 

instantiations  of  data  streams 

DRIVER  procedures 

end  TL; 

Fig.  10  Integration  of  Reusable  Components 
Altizer  in  [Ref.  ll]  describes  an  alternative  method 
for  handling  PSDL  exceptions.  In  his  approach,  a 
distinction  is  made  between  streams  which  carry  normal  data 
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values  and  streams  which  carry  PSDL  exceptions. 


Streams 


which  carry  PSDL  exceptions  are  of  type  PSDL_EXCEPTION  and 
must  be  declared  explicity  by  an  operator.  An  operator 
allowed  to  raise  a  PSDL  exception  can  only  communicate  that 
exception  to  operators  which  are  directly  connected  to  it 
via  an  exception  data  stream.  An  operator  receiving  the 
PSDL  exception  on  its  input  data  stream  is  then  by 
definition  an  exception  handler. 

While  Altizer's  method  was  determined  to  be  easier  to 
implement  than  the  method  originally  proposed  by  Luqi,  it 
was  also  determined  to  be  inadequate.  The  approach  to 
exception  handling  eventually  decided  upon  in  this  thesis 
draws  on  this  approach  but  differs  somewhat.  The  following 
paragraphs  will  describe  an  example  of  a  PSDL  to  Ada 
translation  involving  PSDL  exceptions.  At  that  time  the 
method  adopted  in  this  thesis  should  become  clear. 
Deviations  from  previous  research  in  both  method  and 
implementation  will  be  noted. 

Appendix  B  contains  a  sample  prototype  which  performs 
no  particular  function.  The  example  consists  of  an  enhanced 
data  flow  diagram,  a  prototype  description,  parts  of  its  Ada 
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implementation  and  a  supporting  Ada  package.  Operator  Cl  is 
a  composite  operator.  OP1,  0P2  and  OP3  are  atomic 
operators.  OP1,  0P2  and  0P3  are  subcomponents  of  Cl. 
Operator  EXCEPTION_HANDLER  is  an  atomic  operator.  Its 
purpose  is  to  handle  any  exceptions  raised  by  0P1.  The  data 
streams  visible  in  this  diagram  are  A,  B  and  EXCP.  A  and  B 
are  data  streams  of  normal  data  types.  EXCP  is  an  exception 
data  stream  It  is  of  type  PSDL_EXCEPTION. 

Referring  to  Section  B  of  Appendix  B,  it  can  be  seen 


that  data 

streams  A  and  B 

are 

declared 

to 

be 

of 

type 

INTEGER. 

Data  stream  EXCP 

is 

declared 

to 

be 

of 

type 

PSDL_EXCEPTION.  The  statement 

EXCE1TI0N  OUT_OF_RANGE  IF  A  >  100 
is  a  PSDL  EXCEPTION  statement.  It  is  interpreted  as  "If  the 
value  which  is  to  be  output  to  A  is  greater  than  100,  then 
output  the  PSDL  exception  OUT_OF_RANGE  onto  all  of  the 
operator's  output  data  streams  declared  to  be  of  the 
PSDL_EXCEPTION  data  type.  Do  not  output  the  calculated 
value  onto  A."  This  represents  a  departure  from  previous 
research.  Prior  to  this  thesis,  the  syntax  of  the  EXCEPTION 
statement  required  that  a  target  data  stream  be  specified. 
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In  the  interest  of  efficiency,  it  was  decided  that  the 
default  be  all  data  streams  of  type  PSDL_EXCEPTION  and  that 
if  the  designer  wished  to  suppress  outputting  the  exception 
to  any  particular  stream  he  could  do  so  via  an  Output 
Condition  [Ref.  6:p.  1415-1416]. 

The  statement 

TRIGGERED  BY  ALL  EXCP  IF  EXCP  =  OUT_OF_RANGE 
represents  another  departure  from  previous  research.  It  is 
a  PSDL  triggering  condition  which  is  interpreted  here  as  "If 
there  is  a  new  data  value  on  input  data  stream  EXCP,  then 
consume  the  data  value.  If  the  value  consumed  equals  the 
PSDL  exception  OUT_OF_RANGE ,  then  allow  the  operator 
EXCEPTION_HANDLER  to  execute.  If  the  expression  EXCP  = 
OUT_OF_RANGE  is  not  satisfied,  then  EXCEPTION_HANDLER  is  not 
allowed  to  execute  any  farther  and  is  terminated."  Altizer 
introduced  a  special  operation  in  his  thesis  to  perform  the 
above  function,  which  is  to  determine  if  a  particular 
exception  has  been  raised.  This  was  determined  to  be 
unnecessary.  A  special  note  here.  In  the  above  statement, 
the  condition  EXCP  =  OUT_OF_RANGE  is  optional.  If  this 
condition  is  null,  then  the  presence  of  any  PSDL  exception 
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on  EXCP  will  cause  EXCEPTION_HANDLER  to  execute. 

One  last  item  of  interest  in  Section  B  of  Appendix  B  is 
the  statement 

EXCEPTIONS  NEGATIVE_NUMBER 

This  statement  is  interpreted  as  "During  the  execution  of 
operator  0P1,  its  possible  for  an  Ada  exception 
NEGATIVE_NUMBER  to  be  raised.  If  this  hafpens  convert 
NEGATIVE_NUMBER  into  a  PSDL  exception  and  output  it  onto  all 
data  streams  of  type  PSDL_EXCEPTION,  which  in  this  case  is 
only  one  stream,  EXCP."  This  provides  a  mechanism  for 
interfacing  between  Ada  exceptions  and  PSDL  exception 
handlers.  Ada  exceptions  that  are  not  declared  in  the  PSDL 
specifications  are  treated  as  errors  and  cause  abnormal 
termination  of  the  prototype. 

Section  C  of  Appendix  B  is  a  partial  Ada  implementation 
of  the  prototype  described  in  Section  B.  It  consists  of  two 
packages:  TL  and  SB.  Package  SB  is  as  described  earlier  in 

this  thesis.  It  is  a  package  containing  the  reusable 
components  extracted  from  the  software  base.  Package  TL  is 
the  output  of  the  translator.  It  consists  of  DRIVER 
procedures  which  call  the  components  in  SB. 
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In  both  package  TL  and  package  SB  visibility  is 
established  to  a  package  PSDL_EXCEPTIONS  via  the  Ada  with 
and  use  clauses, 

With  PSDL_EXCEPTIONS ;  use  PSDL_EXCEPTIONS ; 

Package  PSDL_EXCEPTIONS  is  an  Abstract  Data  Type  (ADT) .  Its 
purpose  is  to  define  the  type  PSDL_EXCEPTION  and  various 
operations  applicable  to  objects  of  the  type.  When  the 
reusable  components  were  placed  into  a  separate  package  SB, 
it  was  found  necessary  to  abstract  out  the  type 
PSDLJEXCEPTION  and  to  create  the  ADT.  PSDL_EXCEPTIONS  is 
listed  in  Section  D  of  Appendix  B. 

C.  IMPLEMENTATION  OF  THE  DYNAMIC  SCHEDULER 

As  stated  at  the  beginning  of  this  chapter,  the  execution 
support  system  consists  of  three  major  components:  a 
translator,  a  static  scheduler  and  a  dynamic  scheduler. 
Previous  research  resulted  in  implementations  for  these 
components,  but  they  were  never  integrated  into  a 
functioning  execution  support  system  which  enables  the 
execution  of  prototypes  written  in  PSDL.  Providing  this 
tool  is  the  purpose  of  this  thesis. 
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In  the  case  of  the  translator,  Altizer  [Ref.  11]  provided 
an  implementation  which  when  modified  as  described  earlier, 
was  assimilated  into  the  execution  support  environment.  In 
the  case  of  the  static  scheduler,  Kilic  [Ref.  15]  provided 
an  implementation  which  when  modified  was  assimilated  into 
the  execution  support  environment.  Not  so  with  the  dynamic 
scheduler  though. 

The  dynamic  scheduler  as  implemented  by  Wood  [Ref.  16] 
presented  a  problem.  The  problem  is  that  Wood's  dynamic 
scheduler  is  based  on  a  conceptualization  of  the  execution 
support  system  which  differs  from  the  one  adopted  in  this 
thesis.  As  envisioned  by  Wood,  Fig.  11,  the  translator  is  a 
separate  process  which  can  execute  in  parallel  with  the 
static  scheduler.  The  static  s^neduler  is  part  of  a  system 
containing  the  static  scheduler,  its  debugging  system,  and 
the  process  by  which  the  non-time  critical  operators  are 
transformed  into  executable  code.  The  dynamic  scheduler 
coordinates  the  execution  of  the  critical  and  non-critical 
operators.  It  and  its  debugging  system  form  another 
distinct  part  of  the  execution  support  system. 
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Fig.  1 1  Execution  Support  System,  Previous 

According  to  Wood,  the  translator  and  the  static 
scheduler  produce  three  outputs:  the  executable  code  for 
the  operators,  the  static  schedule  for  the  time-critical 
operators,  and  the  listing  of  procedure  calls  for  the  non- 
time-critical  operators.  These  outputs  must  be  compiled  and 
linked  together  before  the  dynamic  scheduler  can  be  invoked. 
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The  user  interface  in  CAPS  is  responsible  for  invoking  the 
static  scheduler,  the  translator,  and  the  dynamic  scheduler. 
The  user  interface  also  ensures  that  the  outputs  above  are 
compiled  and  linked  before  invoking  the  dynamic  scheduler. 

Owing  to  the  incompatibility  between  Wood's 
conceptualization  and  the  one  in  this  thesis,  it  was 
necessary  then  to  come  up  with  a  new  implementation  for  the 
dynamic  scheduler.  This  is  presented  in  Appendix  C.  As  can 
be  seen,  the  dynamic  scheduler  was  implemented  as  a 
procedure.  It  has  one  input  and  one  output.  Input  consists 
of  the  names  of  the  non-time-critical  operators.  Output 
consists  of  a  task  containing  procedure  calls  to  the  non¬ 
time-critical  operator  DRIVERS  in  package  TL.  Visibility  to 
TL,  as  well  as  to  the  package  PRIORITY_DEFINITIONS ,  is 
provided  via  the  Ada  with  and  use  clauses.  The  output  of 
the  dynamic  scheduler  is  referred  to  as  a  dynamic  schedule 
in  this  thesis.  Fig.  12  is  an  example  schedule. 

One  item  to  take  note  of  in  the  sample  schedule  is  the 
statement 

pragma  priority  (DYNAMIC_SCHEDULE_PRIORITY) ; 
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with  Tl;  use  TL; 

with  PRI0RITYJ5EFIN1T10NS;  use  PR10RITY_DEFINIT!0NS 
package  DS_PACKAGE  is 
task  DYNAMI C_SCHEDULE  is 
pragma  priority  (DYNAMI C_SCHEDUIE_PR IOR 1 TY > ; 
end  DYNAMI C_SCHEDULE; 
end  DS_PACKAGE; 

package  body  DS_PACKAGE  is 
task  body  DYNAMI C_SCHEDULE  is 
begin 
loop 

non_cr i t i ca l_op1_DR I VER; 
non_c  r i t i ca l_op2_DR I  VER ; 
null; 
end  loop; 

end  DYNAMIC_SCHEDULE; 
end  DS_PACKAGE; 

Fig.  12  Sample  Dynamic  Schedule 
A  pragma  is  a  directive  to  the  Ada  compiler.  The  priority 
pragma  specifies  the  priority  of  a  task  or  main  program.  It 
takes  as  a  single  argument  either  an  integer  or  an 
expression  which  evaluates  to  an  integer.  A  task  with  a 

higher  priority  will  execute  before  a  task  with  a  lower 
priority. 

The  static  schedule  is  a  task  which  contains  procedure 
calls  to  the  time-critical  operator  DRIVERS  in  TL.  It  too 
has  a  priority  pragma  statement.  The  pragma  statements  in 
the  dynamic  and  static  schedules  are  set  so  that  the  static 
schedule  always  has  the  higher  priority.  This  is  to  ensure 
that  when  the  static  schedule  needs  the  processor  it  will 
get  it.  The  use  of  Ada's  tasking  facilities  to  control 
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operator  execution  is  a  feature  which  originally  appeared  in 
Wood's  implementation.  Though  as  mentioned  above,  the 
dynamic  scheduler  implementations  are  different,  this  was  a 
feature  that  was  found  to  be  especially  useful  and  thus  was 
incorporated  here. 

D.  MODIFICATIONS  TO  THE  STATIC  SCHEDULER 

Integration  into  the  execution  support  system  of  the 
static  scheduler  Kilic  [Ref.  15]  presented  few  problems  for 
this  author.  Test  cases  run  through  the  scheduler  during 
integration  identified  only  a  single  minor  error  in  the 
actual  functioning  of  the  scheduler;  this  was  quickly 
corrected.  Subsequent  modifications  during  integration 
consisted  entirely  of  changes  of  an  interface  nature.  These 
are  described  below. 

Fig.  13  is  a  sample  static  schedule.  When  Kilic  was 
implementing  the  static  scheduler,  the  work  of  integrating 
the  debugger  into  the  execution  support  system  was  still  in 
its  infancy.  Static  schedules  created  by  the  static 
scheduler  consequently  contained  no  reference  to  the 
debugger.  This  was  changed.  Added  to  static  schedules  now 
are  the  statements 
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with  GLOBAL_DECLARATIONS ;  use  GLOBAL_DECLARATIONS ; 
with  DS_DEBUG_PKG ;  use  DS_DEBUG_PKG ; 

which  establish  visibility  to  the  debugger  and  the  statement 

DS_DEBUG . RUNTIME_MET_FAI LURE  ( 

VARSTRING . VSTR ( "CRITICAL_0P3 " ) , 

CURRENT_TIME ,  CRITICAL_OP3_STOP_TIME3 , 
PERIOD) ; 

which  executes  an  entry  call  to  Runtime_MET_Failure.  The 
actual  functioning  of  the  debugger  is  described  in  the  next 
section  and  will  not  be  covered  here. 

One  item  that  does  need  to  be  covered  here  though  is  the 
use  of  the  Ada  delay  statement  in  the  static  schedule.  It 
was  mentioned  in  the  previous  section  that  priority  pragma 
statements  are  utilized  in  the  dynamic  and  static  schedules 
to  ensure  that  when  the  static  schedule  needs  the  processor 
it  gets  it.  The  question  now  is  "How  does  the  dynamic 
schedule  get  the  processor  then?"  The  answer  is  via  the  Ada 
delay  statement. 

The  delay  statement  is  used  in  Ada  to  suspend  execution 
of  a  task  or  main  body.  When  a  time-critical  operator 
completes  execution  a  check  is  made  to  determine  if  the 
operator's  scheduled  stop  time  is  greater  than  the  current 
time.  If  it  is,  then  the  static  schedule  delays  for  the 
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time  remaining  till  its  stop  time.  Once  it  does  this,  it 
effectively  gives  up  the  processor  to  the  dynamic  schedule. 
When  the  length  of  the  delay  is  over,  the  static  schedule  is 
given  the  processor  back. 


with  GLOBAL_OECLARATIONS;  use  GLOBAL_DECLARAT IONS; 
with  DS_OEBUG_PKG;  use  DS_OEBUG_PKG; 
with  Tl;  use  XL; 

with  DS_PACKAGE;  use  DS_PACKAGE; 

With  PRIORI TY_DEFI NIT  IONS;  use  PRI0RITY_DEF1NITI0NS; 
with  CALENDAR;  use  CALENDAR; 
with  TEXT_IO;  use  TEXT_10; 
procedure  STAT I C_SCHEDULE  is 
CRITICAL_OP3_t7hinG_ERROR  :  exception; 

CR I T I CAL_0P2_T I H I NG_ERROR  :  exception; 

CR I T I CAL_OP 1_T I M I N G_ERROR  :  exception; 
task  SCHEDULE  is 

pragma  priority  <STATIC_SCHEDULE_PR!ORITY); 
end  SCHEDULE; 

task  body  SCHEDULE  is 


begin 

loop 

begin 

CRIT1CAL_0P1_DRIVER; 

SLACK_TIME:=  START_OF_PERIOD  +  CRITICAL_0P1_ST0P_TIME1  -  CLOCK; 
if  SLACK_TIME  >=  0.0  then 
delay  (SLACK_TIME); 
else 

raise  CRITICAL_0P1_T1MING_ERR0R; 
end  if; 

delay  (START_OF_P£RIOO  ♦  CRITICAL_0P1_ST0P_TIHE1  -  CLOCK); 

CR I T I CAL_0P2_0R I VER; 


delay  (START_OF_PERI»  ♦  CRITICAL_0P2_ST0P_TIME2  -  CLOCK); 
CR I T I CAL_0P3_DR I VER ; 


START_0F_PERI00  :=  START_0F_PERI00  +  PERI00; 
delay  (START_0F_PERI00  -  clock); 

Fig.  13  Sample  Static  Schedule 
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except i on 

when  CR I T I CAL_OP3_T ! M ! NG_E  RROR  => 

PUT_LINE("timing  error  from  operator  CRITICAL_0P3H); 
CURRENT_TIME:=  clock  -  START_OF_PERIOO; 
DS_DEBUG.RUNTIME_MET_FAILURE  ( 

VARSTR I NG .  VSTR  (  "CR  I T I  CAL_OP3"  ) , 

CURRENT_TIME,  CRITICAl_0P3_ST0P_TIME3,  PERIM); 
START_OF_PERIOO  :=  clock; 
when  CRITICAL  OP2  TIMING  ERROR  => 


when  CRITICAL  OP1  TIMING  ERROR  => 


end; 

end  loop 
end  SCHEDULE; 

begin 

null; 

end  STAT I C_SCHEDULE ; 


Fig.  13  Continued 


E.  THE  DEBUGGER 
1 .  Background 

There  are  three  kinds  of  exceptions  defined  in  this 
thesis:  Ada  exceptions  not  declared  in  the  prototype 
description,  PSDL  exceptions  defined  by  the  prototype 
designer  to  include  Ada  exceptions  declared  in  the  prototype 
description  and  Ada  exceptions  declared  by  the  PSDL  runtime 
system.  Ada  exceptions  not  declared  in  the  prototype 
description  include  the  predefined  exceptions  declared  in 
package  STANDARD.  The  raising  of  this  type  of  exception 
during  prototype  execution  results  in  abnormal  termination. 
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PSDL  exceptions  defined  by  the  prototype  designer  were 
discussed  in  section  B  of  this  chapter.  Handling  of  these 
exceptions  is  by  the  exception  handler  which  the  designer 
must  provide  in  package  SB.  Ada  exceptions  declared  by  the 
PSDL  runtime  system,  of  which  there  are  three,  are  CAPS 
specific  exceptions  which  can  occur  during  the  execution  of 
any  prototype.  They  are:  BUFFER_UNDERFLOW,  BUFFER_OVERFLOW 
and  OPERATOR_TIMING_ERROR,  where  OPERATOR  is  the  name  that 
was  given  to  the  operator  in  the  prototype  description. 
Exception  BUFFER_UNDERFLOW  is  raised  when  an  operator 
attempts  to  read  from  an  empty  data  stream.  Exception 
BUFFER_OVERFLOW  is  raised  when  an  operator  attempts  to  write 
to  a  dataflow  stream  which  currently  contains  a  value. 
Exception  OPERATOR_TIMING_ERROR  is  raised  when  an  operator 
exceeds  its  MET.  Ada  exceptions  declared  by  the  PSDL 
runtime  system  are  handled  by  the  debugger  which  is 
described  below. 

As  part  of  the  earlier  research  effort  on  CAPS,  in 
addition  to  developing  the  translator,  the  static  scheduler 
and  the  dynamic  scheduler,  work  was  .i.ej  expended  on  the 
development  of  a  runtime  debugger  for  the  execution  support 
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system.  This  work  was  done  primarily  by  Wood  and  is 
described  in  her  thesis  [Ref.  16].  Wood  calls  her  debugger 
the  Dynamic  Scheduler  debugging  system  and  implements  it  as 
a  task  consisting  of  six  entries.  They  are: 
Runt ime_MET_Fai lure,  Buf fer_Underf low,  Buf fer_Overflow, 
Except ion_Error,  Non_Time_Critical_Operators_Done  and 
Static_Schedule_Done.  The  first  four  entries  were  provided 
to  serve  as  handlers  for  the  Ada  exceptions  declared  by  the 
PSDL  runtime  system.  The  latter  two  entries  were  provided 
to  allow  for  graceful  termination  of  the  prototype. 

During  the  course  of  integrating  Wood ' s  debugging 
system  into  the  execution  support  system,  entry 
Exception_Error  was  determined  to  be  unnecessary  and  was 
eliminated.  Entries  Non_Time_Critical_Operators_Done  and 
Static_Schedule_Done  were  determined  to  be  predicated  on  the 
false  assumption  that  all  the  operators  execute  only  once 
and  likewise  were  eliminated.  Thus  the  modified  version  of 
the  Dynamic  Scheduler  debugging  system  called  simply  the 
debugger  in  this  thesis,  consists  of  only  three  entry 
statements.  The  code  is  included  as  Appendix  D. 
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2.  Sample  Session 

The  purpose  of  any  debugger  is  usually  a  twofold  one-to 
identify  errors  and  if  possible,  to  correct  them.  The 
purpose  of  this  debugger  is  no  different.  In  the  case  of 
Buf fer_Underflow  and  Buffer_Overf low,  the  function  performed 
is  one  of  identif ication-a  message  is  printed  to  a  file,  the 
prototype  terminates.  In  the  case  of  Runt ime_MET_Fai lure 
though,  the  function  performed  is  not  only  one  of 
identification,  but  also  one  of  correction. 

Reference  is  made  to  Fig.  14  which  is  repeated  from  the 
previous  section.  When  a  critical  operator  exceeds  its  MET 
during  prototype  execution,  a  TIMING_ERROR  exception  is 
raised.  At  this  point,  control  passes  to  the  exception 
handler,  an  error  message  is  printed  to  the  screen  and  an 
entry  call  is  made  to  Runtime_MET_Failure.  Prototype 
execution  has  in  effect  been  suspended.  Reference  is  now 
made  to  Appendix  D.  Upon  accepting  the  entry,  the  first 
action  the  debugger  takes  is  to  determine  if  the  operator 
which  exceeded  its  MET  is  in  the  Operators_Overrun  list. 
The  Operators_Overrun  list  is  a  list  of  records  where  each 
record  contains  the  name  of  an  operator  that  has  exceeded 
its  MET  and  a  count  of  the  number  of  times  it  has  done  so. 
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with  GLOBAL_DECLARATIONS;  use  GLOBAL_DECLARAT IONS; 
with  DS_DEBUG_PKG;  use  DS_DEBUG_PKG; 
with  TL;  use  TL; 

with  OS_PACKAGE ;  use  DS_PACKAGE; 
with  Pr7oRITY_DEF1NITIONS;  use  PR10RITY_DEFINITI0NS; 
with  CALENDAR;  use  CALENDAR; 
with  TEXT_IO;  use  TEXT_10; 
procedure~ST  AT  I C_SCHEOULE  is 
CRITICAL_OP3_t7mING_ERROR  :  exception; 

CR I T I CAL~0P2_T I M I NG_ERROfi  :  exception; 
CR1TICAL_0P1_TIMJNG_ERR0R  :  exception; 
task  SCHEDULE  is 

pragma  priority  (STATIC_SCHEDULE_PRIORITY); 
end  SCHEDULE; 

task  body  SCHEDULE  is 


begin 

loop 

begin 

CRITICAL_OP1_DRIVER; 

SLACK_TIME:=  START_OF_PERIOD  +  CRITICAL_OP1_STOP_TIME1  -  CLOCK; 
if  SLACK_TIME  >=  0.0  then 
delay  (SLACKTIME); 
else 

raise  CRIT1CAL_0P1_T1M1NG_ERR0R; 
end  if; 

delay  (START_OF_PERIOD  +  CRITICAL_0P1_ST0P_T!ME1  -  CLOCK); 
CRITICAL_OP2_DRI VER; 


delay  (START_OF_PERIOD  +  CRIT1CAL_0P2_ST0P_TIME2  -  CLOCK); 
CRITICAL_OP3_DRI VER; 


START_OF_PERIOD  :=  START_0F_PERI0D  +  PERIOD; 
delay  (START_0F_PER10D  -  clock); 
exception 

when  CRITICAL_OP3_TIMING_ERROR  => 

PUT_LINE("timing  error  from  operator  CRITICAL_0P3"); 
CURRENT_TIME:=  clock  -  START_OF_PER 1 00 ; 

DS_DEBUG . RUNT  I ME_MET_FA I  LURE  ( 
VARSTRING.VSTR("CRTTICAL_0P3"), 

CURRENT_TIME,  CRITICAL_0P3_ST0P_TIME3,  PER  100); 
START_OF_PER 100  :=  clock; 
when  CRITICAL  OP2  TIMING  ERROR  => 


Fig.  14  Sample  Static  Schedule 
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when  CR I T I CAL_OP 1 _T I M I NG_E  RROR  => 

end; 

end  loop 
end  SCHEOULE; 

begin 

null; 

end  STATIC_SCHEDULE; 

Fig.  14  Continued 

If  the  operator  appears  in  the  list,  a  check  is  then  made  to 
determine  if  the  operator  has  exceeded  its  authorized  number 
of  executions.  If  it  has,  an  error  message  is  printed  and 
execution  of  the  prototype  terminates  abnormally.  If  it 
hasn't  exceeded  its  authorized  number  of  executions,  the 
Executed_count  field  in  the  record  is  then  incremented  by 
one,  adjustments  are  made  to  the  operator's  MET,  a  record  of 
the  adjustments  is  printed  to  a  file  called  Information  and 
execution  of  the  prototype  is  resumed. 

Assume  for  the  moment  that  this  is  the  first  time  this 
operator  has  exceeded  its  MET.  Consequently,  it  will  not  be 
found  in  the  Operators_Overrun  list.  At  this  point  the  user 
is  queried  as  to  which  of  two  possible  courses  of  action  he 
would  like  to  take.  This  is  illustrated  in  Fig.  15.  If  the 
user  opts  for  A,  prototype  execution  terminates.  If  the 
user  opts  for  B,  a  record  for  the  operator  is  then  inserted 
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in  the  Operators_Overrun  list,  an  error  message  is  printed 
to  file  Information,  adjustments  are  made  to  the  operator's 
MET  and  a  record  of  this  is  printed  to  Information.  Fig.  16 


timing  error  from  operator  CRITICAl_0P2 

Execution  of  the  prototype  has  been  suspended  because  an 
operator  exceeded  its  maximum  execution  time.  The 
operator  causing  the  error  is: 

CR I T I CAL_0P2 

Do  you  want  to 

A.  Terminate  execution  of  the  prototype? 

B.  Adjust  the  execution  time  of  the  operator  and  continue 
execution  of  the  prototype? 

Type  the  letter  preceding  the  option  you  want. 


Fig.  15  Sample  User  Query 


EXECUTION  HAS  BEEN  SUSPENDED  OR  HAS  TERMINATED  ABNORMALLY 

The  following  operator  did  not  complete  execution 

before  its  maximum  execution  time  was  expired.  The  operator 

which  caused  the  error  is: 

CR I T I CAL_0P2 

The  maximum  execution  time  for  operator  CRITICAL_0P2 
was  increased  by  3.0200000E+00. 

The  new  ending  time  for  operator  CRITICAL_0P2 

from  the  start  of  the  period  within  the  static  schedule 

is  1 .5020000E+01 . 

EXECUTION  HAS  BEEN  SUSPENDED  OR  HAS  TERMINATED  ABNORMALLY 

The  following  operator  did  not  complete  execution 

before  its  maximum  execution  time  was  expired.  The  operator 

which  caused  the  error  is: 

CRITICAL_0P3 

The  maximum  execution  time  for  operator  CRITICAL_0P3 
was  increased  by  1 .7400000E+00. 

The  new  ending  time  for  operator  CRIT1CAL_0P3 

from  the  start  of  the  period  within  the  static  schedule 

is  1.5740000E+01. 


Fig.  16  Contents  of  File  Information 
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is  an  illustration  of  the  possible  contents  of  file 
Information.  Note,  the  printing  of  the  adjustment  times  to 
file  Information  represents  a  modification  to  the  earlier 
implementation . 

F.  ADDITIONAL  RUNTIME  SUPPORT 

In  the  description  of  what  constitutes  a  prototype  at  the 
beginning  of  this  chapter,  reference  was  made  to  a  group  of 
packages  called  simply,  ADDITIONAL  RUNTIME  SUPPORT.  With 
the  exception  of  PRIORITY_DEFINITIONS,  which  was  discussed 
already,  these  packages  provide  various  types  and  operations 
which  are  essential  to  the  prototype's  execution.  In  the 
interest  of  clarity  and  completeness,  the  code  for  these 
packages  is  provided  as  Appendix  E. 
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CHAPTER  V.  PROTOTYPE  EXAMPLE 


This  chapter  contains  a  prototype  description  and  the 
corresponding  prototype  actually  generated  by  the  execution 
support  system  of  CAPS.  The  example  is  based  on  the  command 
and  control  system  for  a  HAWK  Air  Defense  Guided  Missile 
System  Battery.  The  mission  of  the  HAWK  system  is  to  detect 
and  destroy  low  to  medium  altitude,  hostile,  airborne 
targets.  The  HAWK  missile  system  detects,  identifies, 
tracks,  engages,  and  destroys  airborne  targets.  The  system 
performs  these  functions  against  extremely  low-altitiude  and 
medium-altitude  targets  while  retaining  a  high  degree  of 
mobility  for  rapid  deployment  with  the  Army  in  the  field. 

Fig.  T7  is  a  very  small  section  of  the  overall  dataflow 
diagram  for  the  command  and  control  system.  This  particular 
diagram  is  modeling  the  part  of  the  system  that  provides  to 
the  Tactical  Control  Officer  (TCO)  a  continuously  updated 
tactical  summary.  Track  data  are  read,  sorted  by  category 
and  then  written  to  a  tactical  display  located  by  the  TCO. 
Cl  is  a  composite  operator.  READ_TRACKS,  SORT_TRACKS  and 
WRITE_TRACKS  are  atomic  operators  which  represent  the 
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realization  of  Cl 


Fig.  17  Dataflow  Diagram 


Fig.  18  is  the  prototype  description  corresponding  to  the 
dataflow  diagram  in  Fig.  17.  As  can  be  seen,  operators 
READ_TRACKS,  SORT_TRACKS  and  WRITE_TRACKS  are  time-critical. 
More  specifically  though,  they're  periodic.  Every  20 
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seconds  they  will  execute.  A  and  B  are  data  streams.  By 
virtue  of  the  fact  A  does  not  appear  in  a  "TRIGGERED  BY  ALL" 
constraint  of  SORT_TRACKS ,  it  is  a  sampled  stream  and  will 
be  implemented  as  such.  Likewise  for  B.  By  virtue  of  the 
fact  it  does  not  appear  in  a  "TRIGGERED  BY  ALL"  constraint 
of  WRITE_TRACKS ,  it  too  is  a  sampled  stream.  STR_LIST  is  a 
user  defined  type. 

OPERATOR  Cl 
SPECIFICATION 

MAXIMUM  EXECUTION  TIME  14  sec 
END 

IMPLEMENTATION  GRAPH 

A .  RE AD_TRACKS- >SORT_TRACKS 

B .  SOR  T _T  R ACKS - >UR I TE_TR ACKS 

DAI  *  STREAM  A  :  STRJ.IST, 

B  :  STRJ.IST 

CONTROL  CONSTRAINTS 
OPERATOR  READ_TRACKS 
PER  1 00  20  sec 
OPERATOR  S0RT_TRACKS 
PERI00  20  sec 
OPERATOR  UR1TE_TRACKS 
PERIOD  20  sec 

DESCRIPTION  (  text  > 

END 

OPERATOR  READ_TRACKS 

Fig.  18  Prototype  Description 
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SPECIFICATION 

OUTPUT  A  :  STRJ.IST 
MAXIMUM  EXECUTION  TIME  10  sec 

END 

IMPLEMENTATION  ADA  READ_TRACKS 
END 

OPERATOR  SORT_TRACKS 

SPECIFICATION 

INPUT  A  :  $TR_LIST 

OUTPUT  B  :  STRJ.IST 

MAXIMUM  EXECUTION  TIME  2  sec 

END 

IMPLEMENTATION  ADA  SORT_TRACKS 
END 

OPERATOR  URITE_TRACXS 

SPECIFICATION 

INPUT  B  :  STR_LIST 
MAXIMUM  EXECUTION  TIME  2  sec 

END 

IMPLEMENTATION  ADA  UR  I TE_TRACKS 
END 

Fig.  18  Continued 

Fig.  19  is  package  SB  which  contains  the  reusable 
components  extracted  from  the  software  base.  Procedure 
READ_TRACKS  basically  just  keeps  reading  track  data  from 
file  INPUT_FILE  until  it  encounters  the  END_OF_FILE 
condition.  SORT_TRACKS  makes  use  of  the  reusable  component 
QUICKSORT  to  sort  the  tracks  by  category.  And  finally, 
WRITE  TRACKS  writes  the  data  to  the  screen. 
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Fig.  20  is  the  output  of  the  translator  after  it  reads 


and  processes  the  prototype  description  given  in  Fig.  18. 
The  statement 

package  DS_A  is  new  SAMPLED_BUFFER(STR_LIST) ; 
is  the  instantiation  for  data  stream  A.  The  statement 
package  DS_B  is  new  SAMPLED_BUFFER(STR_LIST) ; 


with  TEXTJO;  use  TEXT  JO; 
with  ORDERING; 

with  PSDL  JXCEPT IONS;  use  PSDL  JXCEPTIONS; 
package  SB  is 

type  STRING_REC  is  record 

NAME  :  STRING  (1..80); 
end  record; 

type  STRJIST  is  array  (INTEGER  range  1..10)  of  STRING_REC; 
procedure  READ JRACKS  (DATA  :  in  out  STRJIST); 
procedure  SORTJRACKS  (L  :  in  STRJIST;  M  :  in  out  STRJIST); 
procedure  UR  IT? JRACKS  (L  :  in  STR  LIST); 
end  SB; 

package  body  SB  is 

function  “<"  (X  :  in  STRING_REC; 

Y  :  in  STRING_REC)  return  Boolean  is 

begin 

return  (X.NAME  (1)  <  Y .NAME  (1)); 
end  "<"; 

package  INTJNC  is  new 

ORDERING. QUICKSORT  (STRING_REC,  INTEGER,  •'<"); 
use  I  NT _ INC; 

procedure  READ  JRACKS  (DATA  :  in  out  STRJIST)  is 
INPUT JI LE  :  FILEJYPE; 

I,  LAST  :  INTEGER; 

TEMP_STRING  :  STRING  (1..80); 
begin 

OPEN  (INPUTJILE,  INJILE,  "INPUTJILE"); 
for  J  in  1..10  loop 
for  K  in  1 . .80  loop 
DATA  (J).NAME  (K)  :=  '  '; 
end  loop; 
end  loop; 

I  1; 

while  (not  (END_0F_FI LE  (INPUTJILE)))  loop 
GETJINE  (  INPUT_F  1  LE ,  TEMP_STRING,  LAST); 

DATA  (I). NAME  (1..LAST)  :=  TEMP_STRING  ( 1 . .LAST); 

Fig.  19  Reusable  Components 
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Fig.  20  DRIVER  Procedures 
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C1_SPEC.DS_B. BUFFER. URITE(B); 
end  SORT_TRACKS_DR I VER ; 

procedure  WRITE_TRACtCS_DRIVER  is 
B:  STR_L1ST; 
begin 

C1_SPEC.DS_B. BUFFER. READ(B); 

WrTtE_TRACKS(B); 
end  URITE_TRACKS_DRIVER; 

end  TL; 

Fig.  20  Continued 

is  the  instantiation  for  data  stream  B.  The  procedures 
READ_TRACKS_DRIVER ,  etc.  are  the  drivers  for  the  resuable 
components  given  in  Fig.  19. 

Fig.  21  is  the  output  of  the  dynamic  scheduler.  It 
consists  of  a  package  DS_PACKAGE  containing  a  task 
DYNAMIC_SCHEDULE .  DYNAMIC_SCHEDULE  contains  procedure  calls 
to  the  non-time-critical  operator  DRIVERS  in  package  TL.  In 
the  example  in  this  chapter,  there  are  no  non-time-critical 
operators,  consequently,  DYNAMIC_SCHEDULE  contains  no 
procedure  calls.  Another  important  item  to  take  note  of  is 
the  statement 

pragma  priority  ( DYNAMI C_SCHEDULE_PRIORITY ) ; 

This  statement  is  needed  to  ensure  that  if  the  static 
schedule  and  the  dynamic  schedule  are  both  vying  for  the 
processor,  the  static  schedule  will  get  it.  The  value  of 
this  priority  must  be  less  than  the  value  of  the  priority  in 
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the  static  schedule 


with  TL;  use  TL; 

with  PRIOR ITY_DEFIN1T IONS;  use  PRI0RITY_DEFINIT10NS; 
package  DS_PACKAGE  is 
task  DYNAMI C_SCHEDULE  is 
pragma  priority  (DYNAHIC_SCHEDULE_PR10R1TY); 
end  DYNAMI C_SCHEDULE ; 
end  DS_PACKAGE; 

package  body  DS_PACKAGE  is 
task  body  DYNAMI C_SCHEDUL£  is 
begin 
loop 
null; 
end  loop; 

end  DYNAMI C_SCHEDULE ; 
end  DS_PACKAgI; 

Fig.  21  Dynamic  Schedule 
Fig.  22  is  the  output  of  the  static  scheduler.  It 
consists  of  procedure  calls  to  the  time-critical  operator 
DRIVERS  in  package  TL.  Note  that  the  value  of  the  priority 
here  has  to  be  greater  than  the  value  of  the  priority  in  the 
dynamic  schedule. 


with  GLOBAt_DECLARAT IONS;  use  GLOBAL_DECL ARAT IONS; 
with  DS_DEBUG_PKG;  use  DS_DEBUG_PKG; 
with  TL;  use  TL; 

with  DS_PACKAGE;  use  DS_PACKAGE; 
with  PRIORITY_DEFINITIONS;  use  PRIORITY_DEFINITIONS; 
with  CALENDAR;  use  CALENDAR; 
with  TEXT_IO;  use  TEXTJO; 
proredure~STAT I C_SCHEDULE  is 
WR I TE_TRACKS_T I M I NG_ERROR  :  exception; 

SORT_TRACKS_TIMING_ERROR  :  exception; 

READ_TRACKS_TIMING_ERROR  :  exception; 
task  SCHEDULE  is 

pragma  priority  (STATIC_SCHEDULE_PR!ORITY); 
end  SCHEDULE; 

task  body  SCHEDULE  is 

PERIOO  :  duration  :=  duration(20); 

Fig.  22  Static  Schedule 
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RE AD_TR ACKS_ST OP_T I ME  1  :  duration  :  =  duration(IO); 
SORT_TRACKS_STOP_TIME2  :  duration  :=  duration<12); 
WRITE_TRACKS_ST0P_TIME3  :  duration  :  =  duration<14); 

SLACK~TIME  :  duration; 

START_0F_PER100  :  time  :=  clock; 

CURRENT_T1ME  :  duration; 
begin 
loop 
begin 

READ_TRACKS_DRIVER; 

SLACIC_TIME  :=  START_OF_PERIOO  +  READ_TRACKS_ST0P_T1ME1  -  CLOCK; 
if  SLACK_TIME  >=0.0  then 
delay  (SLACK_TIME); 
else 

raise  RE AD_TRACKS_TIM I NG_ERROR; 
end  if; 

delay  <START_OF_PERIOO  +  READ_TRACKS_ST0P_TIME1  -  CLOCK); 
SORT_TRACKS_DRI  VER; 

SLACK_TIME  :=  START_0F_PER100  +  SORT_TRACKS_STOP_T IHE2  -  CLOCK; 
if  SLACK_TIME  >=  0.0  then 
delay  (SLACK_TIME); 
else 

raise  SORT_TRACKS_TIMING_ERR0R; 
end  if; 

delay  (START_0F_PERI00  +  S0RT_TRACKS_ST0P_TIHE2  -  CLOCK); 
WRITE_TRACKS_DRI VER; 

SLACK_T1ME  :=  START_OF_PERIOD  +  UR1TE_TRACKS_ST0P_TIME3  -  CLOCK 
if  SLACK_TIME  >=  0.0 
delay  <SLACK_TIME); 
else 

ra  i  se  UR  I  TE_TRACKS_T  I H I  NG_ERR0R  ; 
end  if; 

START_JF_PERIOD  :=  START_OF_PER 100  +  PERIOD; 
delay  (START_OF_PERIOD  -  clock); 
exception 

when  UR  I TE_TRACKS_T IMI NG_ERR0R  => 

PUT_L  I  NEC  timing  error  from  operator  URITE_TRACKSM); 
CURRENT_TIME:=  clock  -  ST ART_OF_PER 1 0D ; 

0S_DE8UG . RUNT  I ME_MET_FA I  LURE  ( 

VARSTR I NG . VSTR( "UR  I TE_TRACKS" ) , 

CURRENT_TIME,  URITE_TRACKS_STOP_TIHE3,  PERIOD); 
START_OF_PERIOO  :=  clock; 
when  SORT_TRACKS_T IM I NG_ERR0R  => 

PUT_LINE("timing  error  from  operator  S0RT_TRACKSM); 
CURRENT_TIME:=  clock  -  START_0F_PERI00; 
OS_DEBUG.RUNTIME_MET_FAILURE  ( 

VARSTR I NG.VSTR("SORT_TRACKS"), 

CURRENT_TIME,  S0RT_TRACKS_ST0P_TIME2,  PERIOD); 
START_OF_PERIOO  :=  clock; 
when  READ_TRACKS_T IMlNG_ERROR  => 

PUT_L I NE ("timing  error  from  operator  READ_TRACKS"); 
CURRENT_TIME:=  clock  -  START_0F_PERI00; 

DS_DE8UG.RUNT IME_MET_FAI LURE  ( 

Fig.  22  Continued 
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VAKSTRING. VSTRC "RE AD_TRACKS" ) , 

CURRENT_TIME,  READ_TRACKS_ST0P_T!ME1 ,  PERIOD); 

START_OF_PERIOO  :=  clock; 

end; 

end  loop; 
end  SCHEDULE; 

begin 

null; 

end  STAT I C_SCHEDULE ; 

Fig.  22  Continued 

Once  the  translator,  static  scheduler  and  dynamic 
scheduler  have  completed,  the  user  interface  takes  their 
outputs  as  well  as  the  packages:  PSDL_SYSTEM, 

PSDLJEXCEPTIONS,  SB,  Global_Declarations ,  DS_Debug_PKG , 
TIMERS,  VSTRINGS ,  List_Single_Unbounded_Unmanaged  and 
PRIORITY_DEFINITIONS  and  compiles  and  links  them,  thus 


forming  the  executable  prototype.  This  prototype  is  then 


run.  Fig. 

23  is 

a  sample 

input  for 

the  prototype. 

Fig.  24 

Identified 

Azimuth 

Range  (km) 

Heading 

Speed  (mph) 

hostile 

320 

425 

140 

1500 

unknown 

40 

250 

240 

750 

friendly 

80 

75 

360 

1000 

friendly 

100 

20 

270 

1000 

friendly 

250 

130 

90 

500 

hosti le 

330 

450 

150 

1500 

hosti le 

300 

475 

120 

1500 

unknown 

45 

750 

180 

1000 

unknown 

30 

650 

210 

1000 

Fig.  23 

Sample  Track  Data 

is  the  corresponding  output. 
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Identified 

Azimuth 

Range  (km) 

Heading 

Speed  (mph) 

friendly 

100 

20 

270 

1000 

friendly 

80 

75 

360 

1000 

friendly 

250 

130 

90 

500 

hostile 

300 

475 

120 

1500 

hosti le 

320 

425 

140 

1500 

host i l e 

330 

450 

150 

1500 

unknown 

30 

650 

210 

1000 

unknown 

45 

750 

180 

1000 

unknown 

40 

250 

240 

750 

Fig.  24  Corresponding  Output 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

Integration  is  sort  of  a  nebulous  term.  Integration  as 
used  throughout  this  thesis  has  meant:  1.  make 

modifications  to  the  component  to  make  it  work  if  it  doesn't 
already  and  2.  then  make  modifications  to  the  component  to 
make  it  function  as  part  of  the  execution  support  system. 
In  the  case  of  the  translator,  we  saw  the  need  for  both 
types  of  modifications.  In  the  case  of  the  static  scheduler 
and  of  the  debugger,  just  the  latter  type  of  modification 
was  required.  Finally,  in  the  case  of  the  dynamic  scheduler 
we  had  a  situation  where  modifications  would  have  been  so 
extensive,  that  a  new  implementation  was  deemed  more 
efficient . 

The  purpose  of  this  thesis  was  to  provide  a  tool  that 
enables  the  execution  of  prototypes  written  in  PSDL.  That 
has  been  accomplished.  With  the  addition  of  the  debugger 
the  designer  also  has  the  capability  of  changing  an 
operator's  MET  dynamically  and  of  recording  all  operator 
time  adjustments. 
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B.  RECOMMENDATIONS 


There  are  significant  opportunities  for  future  research 
in  the  area  of  the  execution  support  system.  One 
possibility  is  the  expansion  of  the  debugger.  As  it  is 
currently  implemented,  entries  Buffer_Underflow  and 
Buf fer_Overflow  provide  only  an  identification  type 
function.  If  a  call  is  made  to  either  of  them,  the  only 
action  taken  is  to  print  an  error  message  to  file 
Information  and  then  terminate  the  prototype's  execution. 
Perhaps  the  capability  of  correcting  these  error 
dynamically,  as  it  is  for  Runt ime_MET_Fai lure,  can  be  built 
in  to  the  debugger. 

Another  possibility  for  future  research  is  in  the  way 
that  the  user  interface  interacts  with  the  execution  support 
system.  The  way  that  CAPS  is  implemented  now,  when  the 
designer  finishes  construction  of  the  prototype  description 
and  wishes  to  invoke  the  execution  support  system,  he  or  she 
does  so  by  selecting  an  Execute  option  off  of  a  menu.  What 
happens  then  is  the  user  interface  submits  the  prototype 
description  to  the  translator  for  creation  of  package  TL. 
Once  the  translator  finishes,  the  user  interface  next 
submits  the  prototype  description  to  the  static  scheduler 
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for  processing.  After  the  static  scheduler  finishes,  the 
user  interface  then  invokes  the  dynamic  scheduler.  After 
the  dynamic  scheduler  finishes  the  user  interface  next 
compiles  and  links  the  necessary  files,  creating  the 
executable  prototype  which  is  immediately  run.  At  no  point 
in  this  process  though  does  the  user  interface  query  the 
designer  as  to  whether  or  not  they  would  like  to  continue, 
even  if  something  should  go  awry  along  the  way  like  the 
static  scheduler  not  being  able  to  derive  a  schedule.  The 
user  interface  needs  to  be  changed  so  that  the  Execute 
option  is  broken  down  into  perhaps  three  options  like: 
Translate,  Compile  and  Run. 
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APPENDIX  A.  DATA  STREAM  IMPLEMENTATION 


with  PRIORITY_DEFINITIONS ;  use  PRIORITY_DEFINITIONS ; 
with  vstrings,  TIMERS; 
package  PSDL_SYSTEM  is 

package  PSDL_STRINGS  is  new  vstrings (50) ; 
type  PSDL_TIMER  is  new  TIMERS. TIMER; 

BUFFER_UNDERFLOW ,  BUFFER_OVERFLOW ;  exception; 

generic 

type  E LEMENT_T Y PE  is  private; 
package  SAMPLED_BUFFER  is 
task  BUFFER  is 

pragma  PRIORITY (BUFFER^PRIORITY) ; 
entry  CHECK (NEW_DATA:  out  BOOLEAN) ; 
entry  WRITE (VALUE:  in  ELEMENT_TYPE) ; 
entry  READ (VALUE:  out  ELEMENTJTYPE) ; 
end  BUFFER; 

function  NEW_DATA  return  BOOLEAN; 
end  S AMPLE D_BUFFER; 

generic 

type  ELEMENTJTYPE  is  private; 
package  FIFO_BUFFER  is 
task  BUFFER  is 

pragma  PRIORITY (BUFFER_PRIORITY) ; 
entry  CHECK (NEW_DATA:  out  BOOLEAN); 
entry  WRITE (VALUE:  in  ELEMENT_TYPE) ; 
entry  READ (VALUE:  out  ELEMENTJTYPE) ; 
end  BUFFER; 

function  NEW_DATA  return  BOOLEAN; 
end  FIFO_BUFFER; 

generic 

type  ELEMENT_TYPE  is  private; 

INITI AL_VALUE :  ELEMENT_TYPE ; 
package  STATE_VARIABLE  is 
task  BUFFER  is 

pragma  PRIORITY (BUFFER_PRIORITY) ; 
entry  CHECK (NEW_DATA:  out  BOOLEAN) ; 
entry  READ (VALUE:  out  ELEMENTJTYPE); 
entry  WRITE (VALUE:  in  ELEMENT_TYPE) ; 
end  BUFFER; 

function  NEW  DATA  return  BOOLEAN; 
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end  STATE_VARIABLE ; 
end  PSDL  SYSTEM; 


package  body  PSDL_SYSTEM  is 

package  body  SAMPLED_BUFFER  is 
task  body  BUFFER  is 
BUFFER:  ELEMENTJTYPE ; 

FRESH:  BOOLEAN  :=  false; 
begin 
loop 
select 

accept  CHECK (NEW_DATA:  out  BOOLEAN)  do 
NEW_DATA  :=  FRESH; 
end  CHECK; 
or 

accept  READ (VALUE:  out  ELEMENTJTYPE)  do 
VALUE  :=  BUFFER;  FRESH  :=  false; 
end  READ; 
or 

accept  WRITE (VALUE:  in  ELEMENTJTYPE)  do 
BUFFER  :=  VALUE;  FRESH  :=  true; 
end  WRITE; 
end  select; 
end  loop; 
end  BUFFER; 

function  NEW_DATA  return  BOOLEAN  is 
RESULT:  BOOLEAN; 
begin 

BUFFER. CHECK (RESULT) ; 
return (RESULT) ; 
end  NEW_DATA ; 
end  SAMPLED_BUFFER; 

package  body  FIFO_BUFFER  is 
task  body  BUFFER  is 
BUFFER:  ELEMENTJTYPE ; 

FRESH:  BOOLEAN  :=  false; 
begin 
loop 
select 

accept  CHECK (NEW_DATA:  out  BOOLEAN)  do 
NEW_DATA  :=  FRESH; 
end  CHECK; 
or 

accept  READ (VALUE:  out  ELEMENTJTYPE )  do 
if  FRESH  then 

VALUE  :=  BUFFER;  FRESH  :  =  false; 
else  raise  BUFFER  UNDERFLOW;  end  if; 
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end  READ? 


or 

accept  WRITE (VALUE:  in  ELEMENT_TYPE )  do 
if  not  FRESH  then 

BUFFER  :=  VALUE;  FRESH  :=  true; 
else  raise  BUFFER_OVERFLOW ;  end  if; 
end  WRITE; 
end  select; 
end  loop; 
end  BUFFER; 

function  NEW_DATA  return  BOOLEAN  is 
RESULT:  BOOLEAN; 
begin 

BUFFER . CHECK ( RESULT ) ? 
return (RESULT) ; 
end  NEW_DATA ; 
end  FIFO_BUFFER? 

package  body  STATE_VARIABLE  is 
task  body  BUFFER  is 

BUFFER:  ELEMENT_TYPE  :=  INITIAL_VALUE ; 
FRESH:  BOOLEAN  :  =  true; 
begin 
loop 
select 

accept  CHECK (NEW_DATA:  out  BOOLEAN)  do 
NEW_DATA  :=  FRESH; 
end  CHECK; 
or 

accept  READ (VALUE:  out  ELEMENT_TYPE)  do 
VALUE  :=  BUFFER;  FRESH  :=  false; 
end  READ; 
or 

accept  WRITE (VALUE:  in  ELEMENT_TYPE)  do 
BUFFER  :=  VALUE;  FRESH  :=  true; 
end  WRITE; 
end  select; 
end  loop; 
end  BUFFER? 

function  NEW_DATA  return  BOOLEAN  is 
RESULT:  BOOLEAN; 
begir 

BUFFER. CHECK (RESULT) ; 
return  RESULT; 
end  NiJW_DATA  ; 
end  STATE_VARIABLE ; 
end  PSDL  SYSTEM; 
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APPENDIX  B.  EXCEPTION  HANDLING  EXAMPLE 


This  appendix  contains  a  sample  prototype  which  performs 
no  particular  functic®.  The  purpose  of  this  example  is  to 
illustrate  the  approach  to  exception  handling  adopted  in 

this  thesis. 

A.  DATA  FLOW  DIAGRAM 
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B.  PROTOTYPE  DESCRIPTION 


OPERATOR  Cl 
SPECIFICATION 

MAXIMUM  EXECUTION  TIME  14  sec 
END 

IMPLEMENTATION  GRAPH 

A.  OPl->OP2 

EXCP. OPl->EXCEPTION_HANDLER 

B.  OP2->OP3 

DATA  STREAM  A  :  INTEGER, 

EXCP  :  PSDL_EXCEPTION , 

B  :  INTEGER 

CONTROL  CONSTRAINTS 

OPERATOR  OP1 
PERIOD  20  sec 

EXCEPTION  OUT_OF_RANGE  IF  A  >  100 

OPERATOR  OP2 
PERIOD  20  sec 

OPERATOR  OP3 
PERIOD  20  sec 

OPERATOR  EXCEPTION_HANDLER 

TRIGGERED  BY  ALL  EXCP  IF  EXCP  =  OUT_OF_RANGE 
PERIOD  20  sec 


END 

OPERATOR  OP1 

SPECIFICATION 

OUTPUT  A  :  INTEGER 
OUTPUT  EXCP  :  PSDL_EXCEPTION 
MAXIMUM  EXECUTION  TIME  10  sec 
EXCEPTIONS  NEGATIVE_NUMBER 

END 

IMPLEMENTATION  ADA  OP1 
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END 


OPERATOR  OP2 

SPECIFICATION 

INPUT  A  :  INTEGER 

OUTPUT  B  :  INTEGER 

MAXIMUM  EXECUTION  TIME  2  sec 

END 

IMPLEMENTATION  ADA  OP2 
END 

OPERATOR  OP3 

SPECIFICATION 

INPUT  B  :  INTEGER 

MAXIMUM  EXECUTION  TIME  2  sec 

END 

IMPLEMENTATION  ADA  OP3 
END 

OPERATOR  EXCEPTION_HANDLER 
SPECIFICATION 

INPUT  EXCP  :  PSDL_EXCEPTION 
MAXIMUM  EXECUTION  TIME  2  sec 


END 

IMPLEMENTATION  ADA  EXCE PT I ON_H AN DLER 
END 

C.  PARTIAL  ADA  IMPLEMENTATION  OF  PROTOTYPE  DESCRIPTION 

package  TL  is 

procedure  OPl_DRIVER; 
procedure  OP2_DRIVER; 
procedure  OP3_DRIVER; 
procedure  EXCEPTION_HANDLER_DRI VER ; 
end  TL; 


with  PSDL  SYSTEM?  use  PSDL  SYSTEM; 
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with  PSDL_EXCEPTIONS ;  use  PSDL_EXCEPTIONS ; 
with  SB;  use  SB; 
package  body  TL  is 

package  C1_SPEC  is 

package  DS_A  is  new  SAMPLED_BUFFER( INTEGER) ; 
package  DS_B  is  new  S AMPLE D_BUFFER( INTEGER) ; 
package  DS_EXCP  is  new  FIFO_BUFFER(PSDL_EXCEPTION) ; 

end  C1_SPEC; 

procedure  0P1_DRIVER  is 
A  :  INTEGER; 

begin 
0P1 (A) ; 

if  A  >  100  then 

C1_SPEC . DS_EXCP . BUFFER . WRITE ( INDEX ( CHARACTER_STRING . 
VSTR ( "OUT_OF_RANGE" ) ) ) ; 
else 

C1_SPEC.DS_A. BUFFER. WRITE (A) ; 
end  if; 

exception 

when  NEGATIVE_NUMBER  => 

C1_SPEC . DS_EXCP . BUFFER . WRITE ( INDEX ( CHARACTER_ 
STRING. VSTR ("NEGATIVE_NUMBER") ) ) ; 
end  0P1_DRIVER; 

procedure  OP2_DRIVER  is 
A  :  INTEGER; 

B  :  INTEGER; 

begin 

C1_SPEC.DS_A. BUFFER. READ (A) ; 

0P2 (A,  B) ; 

C1_SPEC.DS_B. BUFFER. WRITE (B) ; 
end  OP2_DRIVER; 

procedure  0P3_DRIVER  is 
B  :  INTEGER; 

begin 

C1_SPEC . DS_B . BUFFER . READ (B) ; 

OP3 (B) ; 

end  0P3_DRIVER; 

procedure  EXCEPTION_HANDLER_DRIVER  is 
EXCP  ;  PSDL  EXCEPTION; 


83 


begin 

if  C1_SPEC.DS_EXCP.NEW_DATA  then 
C1_SPEC . DS_EXCP. BUFFER. READ (EXCP) ; 
if  EXCP  =  ( INDEX ( CHARACTER_STRING . VSTR ( "OUT_OF_ 
RANGE")))  then 

EXCEPTION_HANDLER(EXCP) ; 
end  if; 
end  i f ; 

end  EXCEPTION_HANDLER_DRIVER; 
begin 

DECLARE_EXCEPTION ( CHARACTER_STRING . VSTR ( "OUT_OF_RANGE" ) ) ; 
DECLARE_EXCEPTION (CHARACTER_STRING . VSTR ( " NEG ATI VE_NUMBER " ) 
) ; 

end  TL; 


with  TEXT__IO;  use  TEXT_IO; 

with  PSDL_EXCEPTIONS ;  use  PSDL_EXCEPTIONS ; 
package  SB  is 

NEGATIVE_NUMBER  :  exception; 
procedure  OP1  (DATA  ;  in  out  INTEGER) ; 
procedure  OP2  (L  ;  in  INTEGER;  M  :  in  out  INTEGER) ; 
procedure  OP3  (L  ;  in  INTEGER) ; 

procedure  EXCEPTION_HANDLER  (L  :  in  PSDL_EXCEPTION) ; 
end  SB; 

package  body  SB  is 

procedure  OP1  (DATA  :  in  out  INTEGER)  is 
begin 


if  (DATA  <  0)  then 

raise  NEGATI VE_NUMBER ; 
end  if; 


end  OP1 ; 

procedure  OP2  (L  :  in  INTEGER;  M  :  in  out  INTEGER)  is 
begin 


end  OP2 ; 

procedure  OP3  (L  :  in  INTEGER)  is 
begin 
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end  0P3 ; 


procedure  EXCEPTION_HANDLER  (L  :  in  PSDL_EXCEPTION)  is 
begin 

new_line; 

if  ( CHARACTER_STRING . STR  (NAME  (L) ) )  =  " OUT_OF_RAN GE " 

then 

put_line ( "Out  of  Range"); 

elsif  ( CHARACTER_STRING . STR  (NAME  (L)))  =  "NEGATIVE_ 
NUMBER"  then 

put__line ( "Negative  Number"); 
end  if ; 
new_line; 

end  EXCEPTION_HANDLER; 
end  SB; 

D.  SUPPORTING  ADA  PACKAGE 

with  VSTRINGS ; 

with  List_Single_Unbounded_Unmanaged; 
package  PSDL_EXCEPTIONS  is 
—  Definition  of  Abstract  Data  Type 

type  PSDLJEXCEPTION  is  private; 
package  CHARACTER_STRING  is  new  VSTRINGS  (80) ; 
procedure  DECLARE_EXCEPTION  (E  :  in  CHARACTER_STRING . 
VSTRING) ; 

function  NAME  (E  :  in  PSDL_EXCEPTION)  return  CHARACTER_ 
STRING. VSTRING; 

function  INDEX  (E  ;  in  CHARACTER_STRING. VSTRING)  return 
PSDL_EXCEPTION; 
private 

type  PSDL_EXCEPTION  is  range  1..1000; 
end  PSDL_EXCEPTIONS ; 

package  body  PSDL_EXCEPTIONS  is 

package  EXCEPTION_LIST  is  new 

List_Single_Unbounded_Unmanaged  (Item  =>  CHARACTER_ 
STRING. VSTRING) ; 

DECLARED_EXCEPTIONS  :  EXCEPTION_LIST . List ; 

function  IS_EQUAL  (LEFT  ;  in  CHARACTEK_STRING .VSTRING ; 

RIGHT  :  in  CHARACTER_STRING. VSTRING) 

return  BOOLEAN  is 
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begin 

return  ( CHARACTER_STRING . (LEFT,  RIGHT)); 
end  IS_EQUAL; 

procedure  DECLARE_EXCEPTION  (E  :  in  CHARACTER_STRING 

. VSTRING)  is 

begin 

EXCEPTION_LIST. Construct  (E,  DECLARED_EXCEPTIONS) ; 
end  DECLARE_EXCEPTION; 

function  NAME  (E  :  in  PSDL_EXCEPTTCN)  return  CHARACTER_ 
STRING. VSTRING  is 

TEMPORARY_LIST  :  EXCEPTION_LIST. List  :=  DECLARED_ 
EXCEPTIONS ; 
begin 

for  INDEX  in  1 . . (E-l)  loop 

TEMPORARY_LI ST  :=  EXCEPTION_LIST.Tail_Of  (TEMPORARY_ 
LIST) ; 
end  loop; 

return  (EXCEPTION_LIST.Head_Of  (TEMPORARY_LIST) ) ; 
end  NAME; 

function  INDEX  (E  :  in  CHARACTER_STRING. VSTRING)  return 
PSDLJEXCEPTION  is 

TEMPORAR Y_LI S T  :  EXCEPTION_LIST . List  :  =  DECLARED_ 
EXCEPTIONS ; 

I  ;  PSDL_EXCEPTION  :  =  1; 
begin 

while  not  EXCEPTION_LIST. Is_Null  (TEMPORARY_LIST)  loop 
if  IS_EQUAL  (E,  EXCEPTION_LIST.Head_Of  ( TEMPORAR Y_ 
LIST) )  then 
return  I; 
else 

TEMPORAR Y_LI ST  :=  EXCEPTION_LIST. Tail_Of  (TEMPORARY 
LIST) ; 

I  :=  I  +  1; 
end  if; 
end  loop; 
end  INDEX; 

end  PSDL  EXCEPTIONS; 
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APPENDIX  C.  DYNAMIC  SCHEDULER  IMPLEMENTATION 


with  TEXT_IO ;  use  TEXT_IO; 
procedure  DYNAMIC_SCHEDULER  is 


NON_CRITS 

DSV3 

IN_STRING 

LAST 


FILE_TYPE ; 
FILE_TYPE; 
STRING (1. .72) ; 
NATURAL; 


begin 

OPEN (NON_CRITS ,  IN_FILE, 
"/n/suns2/work/caps/prototypes/non_crits" ) ; 

CREATE (DSV3,  OUT_FILE, 
"/n/suns2/work/caps/prototypes/ds . a" ) ; 

PUT_LINE ( DSV3 ,  "with  TL?  use  TL;"); 

PUT_LINE (DSV3 ,  "with  PRIORITY_DEFINITIONS ;  use 
PRIORITY_DEFINITIONS ; "); 

PUT_LINE ( DSV3 ,  "package  DS_PACKAGE  is"); 

PUT_LINE (DSV3 ,  "  task  DYNAMIC_SCHEDULE  is"); 

—  system  defined  priority  for  dynamic  schedule 
PUT_LINE ( DSV3 ,  "  pragma  priority 

(DYNAMIC_SCHEDULE_PRIORITY) ;") ; 

PUT_LINE ( DSV3 ,  "  end  DYNAMIC_SCHEDULE ; " ) ; 

PUT_LINE ( DSV3 ,  "end  DS_PACKAGE ; " ) ; 

NEW_LINE (DSV3 ) ; 

PUT_LINE ( DSV3 ,  "package  body  DS_PACKAGE  is"); 
PUT_LINE ( DSV3 ,  "  task  body  DYNAMIC_SCHEDULE  is"); 
PUT_LINE ( DSV3 ,  »  begin"); 

PUT_LINE ( DSV3 ,  "  delay  (1.0);"); 

PUT_LINE ( DSV3 ,  "  loop"); 

while  not  END_OF_FILE (N0N_CRITS)  loop 
begin 

GET_LINE(NON_CRITS,  IN_STRING,  LAST); 

PUT ( DSV3 ,  "  " ) ; 

for  INDEX  in  1 . . LAST  loop 

PUT ( DSV3 ,  IN_STRING ( INDEX ) ) ; 
end  loop; 

PUT_LINE ( DSV3 ,  " ; " ) ; 
end; 


end  loop; 

PUT_LINE ( DSV3 ,  "  null ; " ) ; 

PUT_LINE (DSV3 ,  "  end  loop;"); 

PUT_LINE ( DSV3 ,  »  end  DYNAMIC_SCHEDULE ; " ) ; 
PUT_LINE ( DSV3 ,  " end  DS_PACKAGE ; " ) ; 
end  DYNAMIC  SCHEDULER; 
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APPENDIX  D.  DEBUGGER 


This  package  contains  information  that  must  be  declared  globally 
for  the  Dyr>amic_Scheduler  procedure. 

The  library  unit  VSTRINGS  is  a  generic  string  package.  It 
contains  the  data  type  VSTRING  and  procedures  to  manipulate  these 
strings.  Since  VSTRINGS  is  generic,  it  must  be  instantiated.  The  name 
of  the  instantiation  must  then  be  made  visible. 

The  instantiation  is  declared  in  a  package  so  .hat  type 
compatibility  will  be  ensured  among  variables  that  the 
Dynamic_Scheduler  will  share  among  tasks. 


with  VSTRINGS; 


package  Global_Declarations  is 

package  VARSTRING  is  new  VSTRINGS  (160); 
use  VARSTRING; 
end  Global_Declarations; 


with  Global_Oeclarations; 
use  Global_Declarations; 

with  TEXT  JO,  CALENDAR ; 
use  TEXTJO,  CALENDAR; 

package  DS_Debug_PKG  is 

The  specification  for  task  DS_Debug  contains  three  entry  statements.*- - 
--•These  statements  identify  errors  that  may  be  encountered  when  the  opera-*-- 
--*tors  execute. *-- 

task  DS_Debug  is 

pragma  priority  (10); 

entry  Runt ime_MET_Fai lure  (Except ion_Operator  :  VARSTRING. VSTRING; 

Current_Time  :  in  duration; 
Operator_Ending_Time  ;  in  out  duration; 

Period  :  in  out  duration); 

--*  The  in  value  for  Current_Time  is  the  time  the  operator  completed*-- 
--•execution.  The  out  value  for  Current_Time  is  the  adjusted  time*-- 
- -‘backgrounds.  Next_Start  has  as  its  value  the  time  the  next  oper-*-- 
--*ator  must  start  execution. *-- 

entry  BufferJJnderf low;  --input  queue  empty 
entry  Buffer_0verf low;  --output  queue  full 
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end  DS_Debug; 
end  DS_Debug_PKG; 

package  body  DS_0ebug_PKG  is 
task  body  DS_Debug  is 
type  NOOE; 

type  LINK  is  access  NOOE; 

type  NOOE  is 
record 

Operator  :  VAR5TRING.VSTR1NG;  --name  of  operator  exceeding  MET 
Executed_count  :  NATURAL;  --nunber  of  times  operator  has  executed 
Next  :  LINK; 
end  record; 

package  FLOATIO  is  new  TEXTJO.FLOATJO  (FLOAT); 

Except ion_Operator  :  VARSTRING.VSTR1NG;  --operator  causing  error 
Information  :  FILE_TYPE;  --file  containing  error  information 
Error_Exists  :  BOOLEAN  :=  FALSE; 

Found  :  BOOLEAN  :=  FALSE;  --indicates  if  operator  already  in  list 
Choice  :  CHARACTER  :=  ‘A1;  --operator's  decision  as  to  continue/terminate 
Operators_Overrun  :  LINK  :=  null;  --list  of  operators  that  have  exceeded 

--  their  MET 

Current  :  LINK;  --pointer  to  operator  in  list 
Difference  :  DUkaTION;  --time  over  MET 

Max_Execut i ons  :  CONSTANT  NATURAL  :=  5;  --maximum  number  of  times  an 

--operator  whose  MET  is  exceeded 
--can  operate 

--*  The  Find  procedure  identifies  whether  the  operator  is  in  the  list.*-- 
--•Name  contains  the  name  of  the  operator  with  the  runtime  error.  If  the*-- 
--•operator  is  in  the  list.  Current  will  point  to  it.  If  the  operator  is*-- 
--*not  in  the  list.  Current  will  point  to  the  last  node  in  the  list.  The*-- 
--•value  of  Found  will  identify  if  the  operator  is  already  in  the  list.*-- 

procedure  Find  (Head  :  in  LINK;  Name  :  in  VARSTRING.VSTRING; 

Current  :  in  out  LINK;  Found  :  out  BOOLEAN)  is 

begin 

Current  :=  Head; 

if  Current  =  null  then  --if  no  nodes  in  list 
Found  :=  FALSE; 

elsif  Current. Next  =  null  then  --if  only  or*  node  in  list 
if  VARSTRING.equal  (Current .Operator,  Name)  then 
Found  :=  TRUE; 
else 

Found  :=  FALSE; 
end  if; 

else  --traverse  list 

while  Current. Next  /=  null 
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loop 

if  VARSTRING.equat  (Current. Operator,  Name)  then 
Found  :=  TRUE; 
end  if; 

Current  :*  Current. Next; 
end  loop; 

--  when  traversing  list,  the  last  node  wilt  not  be  examined. 
--  following  "if"  ensures  last  node  examined 
if  Current .Next  *  null  then 

if  VARSTR INC. equal  (Current. Operator,  Name)  then 
Found  :=  TRUE; 
else 

Found  :=  FALSE; 
end  if; 
end  if; 
end  if; 
end  Find; 

*  The  Insert  procedure  will  place  a  node  at  the  end  of  the  list.  The*- 
•rtode  will  contain  the  name  of  the  operator  with  the  error  and  the  number* 
•of  times  the  operator  has  executed.  The  number  is  initialized  to  one.*-- 

procedure  Insert  (Head  :  in  out  LINK;  Name  :  VARSTRING. VSTRING)  is 
Temp_Pt  :  LINK; 

New_Node  :  LINK; 

begin 

New_Node  :=  new  NODE'  (Name,  1,  null); 

if  Head  =  null  then 
Head  :=  New_Node; 
else 

Temp_Pt  :=  Head; 
while  Temp_Pt.Next  /=  null 
loop 

Temp_Pt  :=  Temp_Pt.Next; 
end  loop; 

Temp_Pt.Next  :=  New_Node; 
end  if; 
end  Insert; 

*  The  next  five  procedures  print  an  error  message  to  the  file  Informa-*- 
•tion.  The  name  of  each  procedure  indicates  the  name  of  the  error  it  is*- 
•processing.  The  last  procedure  is  called  when  an  operator  has  executed*- 
•more  frequently  than  the  permitted  number  of  executions  (for  an  operator* 
•exceeding  its  MET).*-- 

procedure  Print_Buffer_Underf low_Message  (Information  :  FILE_TYPE)  is 
begin 

PUT  (Information,  "EXECUTION  TERMINATED  ABNORMALLY."); 
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NEU_LINE  (Information); 

PUT  (Information,  "There  was  an  attempt  to  read  a  data  buffer  ") 
PUT  (Information,  "that"); 

NEU_IINE  (Information); 

PUT  (Information,  "contained  no  data."); 

NEWJ.INE  (Information); 
end  Pri nt_Buf f erJJnderf low_Message; 

procedure  Print_Buf fer_Overf low_Message  (Information  :  FILE_TYPE)  is 
begin 

PUT  (Information,  "EXECUTION  TERMINATED  ABNORMALLY."); 

NEU_L I NE  (Information); 

PUT  (Information,  “There  was  an  attempt  to  store  data  into  a  "); 
PUT  (Information,  "data  buffer"); 

NEUJ.INE  (Information); 

PUT  (Information,  "that  was  already  full."); 

NEW_L I NE  (Information); 
end  Print_8uffer_Overf low_Message; 

procedure  Print_Runtime_MET_Fai lure_Message  (Information  :  FILE_TYPE; 

Exception_Operator  :  VARSTR I NG . VSTR I NG )  is 

begin 

PUT  (Information,  "EXECUTION  HAS  BEEN  SUSPENDED  OR  HAS  »); 
PUT_LINE  (Information,  “TERMINATED  ABNORMALLY"); 

NEW_LINE  (Information); 

PUT  (Information,  "The  following  operator  did  not  complete  "); 

PUT  (Information,  "execution  "); 

NEWJ.INE  (Information); 

PUT  (Information,  "before  its  maximum  execution  time  was  "); 

PUT_L I NE  (Information,  "expired.  The  operator"); 

PUT  (Information,  "which  caused  the  error  is:"); 

NEIM.INE  (Information); 

PUT  (Information,  "  "); 

VARSTRING.PUT  (Information,  Except ion_Operator); 

NEW_L I NE  (Information); 

NEWJ.INE  (Information); 
end  Print_Runtime_MET_Fai lure_Message; 

procedure  Print_Adjustments_Made_Message  (Information  :  FILE_TYPE; 
Except  ion_Operator  :  VARSTR  I  NG.  VSTR  I  NG;  Difference  :  induration; 
Operator_Ending_Time  :  in  duration;  Period  :  in  duration)  is 
begin 

PUT  (Information,  "The  maximum  execution  time  for  operator  "); 
VARSTR1NG.PUT_LINE  (Information,  Except ion_Operator); 

PUT  (Information,  "was  increased  by  "); 

FLOATIO.PUT  (Information,  FLOAT(Difference),  3,  7); 

PUT_L I NE  (Information,  "."); 

PUT  (Information,  "The  new  ending  time  for  operator  "); 
VARSTRING.PUT_LINE  (Information,  Exception_Operator); 

PUT  (Information,  "from  the  start  of  the  period  within  the  "); 
PUT_L INE  (Information,  "static  schedule  "); 
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PUT  (Information,  "is  "); 

FLOATIO.PUT  (Information,  FLOAT(Operator_Ending_Time),  3,  7); 
PUT_LINE  (Information,  ".«); 

MEW_LINE  (Information);  • 

end  Print_Adjustments_Hade_Message; 

procedure  Print_Too_Many_Executions_Nessage  (Information  :  F1LE_TYPE; 

Except ion_Operator  :  VARSTRING.VSTRING)  is 

begin 

PUT  (Information,  "EXECUTION  TERMINATED  ABNORMALLY."); 

PUT  (Information,  "The  following  operator,  which  executes  "); 
PUT_LINE  (Information,  "frequently,  has  a  maximum"); 

PUT  (Information,  "execution  time  that  is  not  long  enough.  "); 
PUTJ.INE  (Information,  "Execution  has  been"); 

PUT  (Information,  “terminated  because  processing  time  is  being  "); 
PUT_LINE  (Information,  "wasted  by  having"); 

PUT  (Information,  "to  handle  the  error  each  time  the  operator  "); 
PUT_LINE  (Information,  "executes.  The  operator  is:"); 

PUT  (Information,  "  "); 

VARSTR I NG . PUT_L I NE  (Information,  Except ion_Operator); 
end  Pr i nt_T oo_Many_Execut i ons_Message; 

*  The  following  procedure  is  called  when  an  operator  first  exceeds  its*-- 
*MET.  The  procedure  queries  the  user  as  to  whether  to  terminate  or  not.*-- 
•The  user  is  given  three  attempts  to  input  valid  data  -  either  A  or  B.*-- 
*lf  he  has  not  provided  valid  data,  the  procedure  will  return  a  value*-- 
*of  A  to  terminate  execution.  Also,  the  procedure  wiLl  print  a  message*-- 
‘stating  that  execution  has  been  terminated  due  to  invalid  input.*- - 


procedure  Obtain_User_Choice  (Except ion_Operator  :  VARSTRING.VSTRING; 

Choice  :  in  out  CHARACTER)  is 


Count  :  INTEGER; 


procedure  Print_Too_Many_Tries_Message  is 
begin 

NEW_L I NE ; 

PUT  ("You  exceeded  the  number  of  attempts  authorized  to  "); 
PUT  ("enter  data."); 

NEW_LINE; 

PUT  ("Therefore,  execution  of  the  prototype  has  been  "); 

PUT  ("terminated."); 

NEU_LINE; 

end  Print_Too_Many_Tries_Message; 


begin 

Count  :=  1; 

NEW_LINE; 

NEW_LINE; 

PUT  ("Execution  of  the  prototype  has  been  suspended  because  an"); 
NEU_LINE; 

PUT  ("operator  exceeded  its  maximum  execution  time.  The"); 


92 


NEWJ.INE; 

PUT_L 1 NE  ("operator  causing  the  error  is;  "); 

PUT  (»  »); 

VARSTR I NG . PUT  (Except i on_Opera tor ) ; 

NEW_UNE; 

NEW_LINE; 

PUT_LINE  ("Do  you  want  to  “); 

PUT_llN£  ("A.  Terminate  execution  of  the  prototype?" ); 

PUT  (“B.  Adjust  the  execution  time  of  ths  operator  and  continue"); 
NEUJ.INE; 

PUT  (■'  execution  of  the  prototype?11); 

NEW_LINE; 

NEU_LINE; 

PUTJ.INE  (“Type  the  letter  preceding  the  option  you  want."); 
loop 

GET  (Choice); 

NEW_LINE; 

NEWJ.INE; 

if  Choice  =  'a'  then 
Choice  ;=  'A1; 
end  if; 

if  Choice  =  ‘b1  then 
Choice  :=  • B • ; 
end  if; 

exit  when  Choice  =  'A1  or  Choice  =  'B'  or  Count  =  3; 

PUT  ("You  typed:  "); 

PUT  (Choice); 

NEVM.INE; 

PUT_HNE  ("You  must  type  either  A  or  B."); 

Count  :=  Count  ♦  1; 
end  loop; 

if  Choice  /=  'A'  and  Choice  /=  'B'  then 
Choice  :=  'A'; 

Print_Too_Many_Tries_Message; 
end  if; 

end  Obtain_User_Choice; 


begin 

create  (FILE 


MODE 

NAME 


--  main  body  of  task  DS_Debug 
=>  Information, 

=>  OUT_FILE, 

=>  "Information"); 
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loop 

select 

accept  BufferJJnderf low  do 
Error_Exists  :=  true; 

Print_Buffer_Underf low_Message  (Information); 
end  Buf ferJJnderf tow; 
or 

accept  Buffer_Overf low  do 
Error_Exists  :=  true; 

Print_Buf fer_Overf low_Hessage  (Information); 
end  Buffer_Overf low; 
or 

accept  Runt ime_MET_Fai lure 

(Except ion_Operator  :  VARSTRING.VSTRING; 
Current_Time  :  in  duration; 
Operator_Ending_Time  :  in  out  duration; 

Period  :  in  out  duration)  do 

Find  (Operators_0verrun,  Except ion_Operator,  Current,  Fourtd); 
--is  operator  in  Operators_Overrun  list? 

if  Found  then  --check  number  of  executions 

--if  operator  executed  less  than  that  authorized,  update 
if  Current.Executed_count  <=  Max_Execut i ons  then 

Current .Executed_count  :=  Current. Executed_count  +  1; 
else  --terminate  and  print  error  message 

Error_Exists  :=  true; 

PUTJ.INE  ("EXECUTION  TERMINATED  ABNORMALLY."); 

Pr i nt_T oo_Many_Execut i ons_Message  ( I nf ormat i on. 

Except i on_Operator ) ; 

end  if; 

else  --query  user  as  to  terminate/continue 

Obtain_User_Choice  ( Except ion_Operator,  Choice); 

case  Choice  is 

when  'A'  =>  Error_Exists  :=  true;  --terminate 
when  1 B *  =>  Insert  (Operators_Overrun, 

Except ion_Operator); 

--insert  operator  into  Operators_Overrun  list 
when  others  =>  null; 
end  case; 

Print_Runtime_MET_Fai lure_Message  (Information, 

Except ion_Operator); 

--print  error  message  first  time  operator  exceeds  MET 

end  if; 

Difference  :=  Current_Time  -  Operator_Ending_Time; 

--calculate  time  over  MET 

Operator_Ending_Time  :=  Operator_Ending_Time  +  Difference; 
--reset  time  to  the  new  operator  ending  time 
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Period  :=  Period  ♦  Difference; 
Print_Adjustments_Hade_Message  (Information, 

Except ion_Operator,  Difference, 
Operator_Endirvg_Time,  Period); 

end  Runtime_MET_Failure; 
end  setect; 

if  Error_Exists  then 
close  (Information); 
exit; 
end  if; 

end  loop; 
end  DS_0etxjg; 
end  Ds__Debug_PKG; 
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APPENDIX  E.  ADDITIONAL  RUNTIME  SUPPORT 


A.  TIMERS 

With  CALENDAR; 
package  TIMERS  is 

subtype  MICROSEC  is  NATURAL; 
type  TIMER  is  private; 

procedure  RESET  (NAME  :  in  out  TIMER); 

procedure  START  (NAME  :  in  out  TIMER); 

procedure  STOP  (NAME  :  in  out  TIMER); 

function  READ  (NAME  :  in  TIMER)  return  MICROSEC; 

function  LT  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN; 

function  LT  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN; 

function  GT  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN; 

function  GT  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN; 
function  LTE  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN; 

function  LTE  (T  :  MICROSEC;  PT  ;  TIMER)  return  BOOLEAN; 

function  GTE  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN; 

function  GTE  (T  ;  MICROSEC;  PT  :  TIMER)  return  BOOLEAN; 

function  EQU  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN; 

function  EQU  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN; 

private 

type  STATE  is  (INITIAL,  RUNNING,  STOPPED); 
type  TIMER  is 
record 

START_TIME, 

STOP_T IME  :  CALENDAR. TIME; 

ELAPSED_TIME  :  DURATION; 

PRESENT_STATE  :  STATE; 
end  record; 

end  TIMERS; 


Mith  CALENDAR; 

use  CALENOAR; 

package  body  TIMERS  is 

CONVERS!ON_FACTOR  :  constant  DURATION  :=  1000000.0;  -*  converts  elapsed 

--  time  to  microsec's 
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function  READ  (NAME  :  in  TIMER)  return  MICROSEC  is 


begin 

case  NAME. PRESENT  STATE  is 


when  RUNNING  =>  return  MICROSEC (CLOCK 

-  NAME  .START_TIME 
+  NAME. ELAPSED  TIME) 


when  others  =>  return  M I CROSE C ( NAME . E L APSED_T I ME ) ; 
end  case; 

end  READ; 


procedure  RESET  (NAME  :  in  out  TIMER)  is 
begin 

case  NAME.PRESENT_STATE  is 

when  STOPPED  =>  NAME ,ELAPSED_TIME  :=  0.0; 

NAME.PRESENT_STATE  :=  INITIAL; 

when  others  =>  null; 

end  case; 

end  RESET; 


procedure  START  (  NAME  :  in  out  TIMER)  is 
begin 

case  NAME. PRESENT_ST ATE  is 
when  RUNNING  =>  null; 


when  others 

end  case; 
end  START; 


NAME .START_TIME  :=  CALENDAR. CLOCK; 
NAME. PRESENT_ST ATE  :=  RUNNING; 


procedure  STOP  (NAME  :  in  out  TIMER)  is 
begin 

case  NAME .PRESENT_STATE  is 

when  RUNNING  =>  NAME . ELAPSE0_T IME  :=  CALENDAR. CLOCK 
-  NAME. START  TIME 
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when  others 
end  case; 
end  STOP; 


♦  NAME . E  L APSED_T 1 ME ; 
NAME.PRESENT_STATE  :=  STOPPED; 

=>  null; 


function  LT  (PT  :  TIMER;  T  :  rt'.CROSEC)  return  BOOLEAN  is 
begin 

return  FLOAT  ( PT . E L APSED_T I ME  *  CONVERS10N_FACTOR)  <  FLOAT(T) 
end  LT; 

function  LT  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN  is 
begin 

return  LT  (T,PT)  =  GTE  (PT,T); 
end  LT; 


function  GT  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN  is 


begin 

return  FLOAT  ( PT . E L APSED_T I ME  *  CONVERSION_FACTOR)  >  FLOAT(T) 
end  GT; 


function  GT  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN  is 
begin 

return  GT  (T,PT)  =  LTE  (PT,T); 
end  GT; 


function  EQU  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN  is 
begin 

return  not  LT(PT,T)  and  not  GT  (PT,T); 
end  EQU; 


function  EOU  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN  is 
begin 

return  not  LT  (PT,T)  and  not  GT  (PT,T); 
end  EQU; 


function  LTE  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN  is 
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begin 

return  not  GT  (PT,T); 
end  LTE; 


function  LTE  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN  is 
begin 

return  not  GT  (PT,T); 
end  LTE; 

function  GTE  (PT  :  TIMER;  T  :  MICROSEC)  return  BOOLEAN  is 
begin 

return  not  LT  (PT,T); 
end  GTE; 

function  GTE  (T  :  MICROSEC;  PT  :  TIMER)  return  BOOLEAN  is 
begin 

return  not  LT  (PT,T); 
end  GTE; 


end  TIMERS; 
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B.  VSTR1NGS 


-  UNIT:  generic  package  spec  of  VSTRINGS 

-  FILES:  vstring_spec.a  in  publiclib 

related  file  is  vstring_body.a  in  publiclib 

-  PURPOSE:  An  implementation  of  the  abstract  data  type  "variable- length 

string." 

-  DESCRIPTION:  This  package  provides  a  private  type  VSTRING.  VSTRING  objects 

are  "strings"  that  have  a  length  between  zero  and  LAST,  where 
LAST  is  the  generic  parameter  supplied  in  the  package 
instantiation. 

In  addition  to  the  type  VSTRING,  a  subtype  and  two  constants 
are  declared.  The  subtype  STRINDEX  is  an  index  to  a  VSTRING, 
The  STRINDEX  constant  FIRST  is  an  index  to  the  first  character 
of  the  string,  and  the  VSTRING  constant  NUL  is  a  VSTRING  of 
length  zero.  NUL  is  the  default  initial  value  of  a  VSTRING. 

The  following  sets  of  functions,  procedures,  and  operators 
are  provided  as  operations  on  the  type  VSTRING: 

ATTRIBUTE  FUNCTIONS:  LEN,  MAX,  STR,  CHAR 

The  attribute  functions  return  the  characteristics  of 
a  VSTRING. 

COMPARISON  OPERATORS:  »=",  "/=",  "<«,  »>",  "<=»,  ">=" 

The  comparison  operators  are  the  same  as  for  the  predefined 
type  STRING. 

INPUT/OUTPUT  PROCEDURES:  GET,  GETJ.INE,  PUT,  PUTJ.INE 

The  input/output  procedui es  are  similar  to  those  for  the 
predefined  type  STRING,  with  the  following  exceptions: 

-  GET  has  an  optional  parameter  LENGTH,  which  indicates 
the  number  of  characters  to  get  (default  is  LAST). 

-  GETJ.INE  does  not  have  a  parameter  to  return  the  length 
of  the  string  (the  LEN  function  should  be  used  instead). 

EXTRACTION  FUNCTIONS:  SLICE,  SUBSTR,  DELETE 
The  SLICE  function  returns  the  slice  of  a  VSTRING  between 
two  indices  (equivalent  to  STR(X)(A  ..  B)). 

SUBSTR  returns  a  substring  of  a  VSTRING  taken  from  a  given 
index  and  extending  a  given  length. 
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The  DELETE  function  returns  the  VSTRING  which  results  from 
removing  the  slice  between  two  indices. 

EDITING  FUNCTIONS:  INSERT,  APPEND,  REPLACE 
The  editing  functions  return  the  VSTRING  which  results  from 
inserting,  appending,  or  replacing  at  a  given  index  with  a 
VSTRING,  STRING,  or  CHARACTER.  The  index  must  be  in  the 
current  range  of  the  VSTRING;  i.e.,  zero  cannot  be  used. 

CONCATENATION  OPERATOR:  "4" 

The  concatenation  operator  is  the  same  as  for  the  type 
STRING.  It  should  be  used  instead  of  APPEND  when  the 
APPEND  would  always  be  after  the  last  character. 

POSITION  FUNCTIONS:  INDEX,  RINDEX 

The  position  functions  return  an  index  to  the  Nth  occurrence 
of  a  VSTRING,  STRING,  or  CHARACTER  from  the  front  or  back 
of  a  VSTRING.  Zero  is  returned  if  the  search  is  not 
successful . 

CONVERSION  FUNCTIONS  AND  OPERATOR:  VSTR,  CONVERT,  «♦" 

VSTR  converts  a  STRING  or  a  CHARACTER  to  a  VSTRING. 

CONVERT  is  a  generic  function  which  can  be  instantiated  to 
convert  from  any  given  variable- length  string  to  another, 
provided  the  FROM  type  has  a  function  equivelent  to  STR 
defined  for  it,  and  that  the  TO  type  has  a  function  equiv¬ 
elent  to  VSTR  defined  for  it.  This  provides  a  means  for 
converting  between  VSTRINGs  declared  in  separate  instant¬ 
iations  of  VSTRINGS.  When  instantiating  CONVERT  for 
VSTRINGs,  the  STR  and  VSTR  functions  are  implicitly  defined, 
provided  that  they  have  been  made  visible  (by  a  use  clause). 

Note:  CONVERT  is  NOT  implicitly  associated  with  the  type 
VSTRING  declared  in  this  package  (since  it  would  not  be  a 
derivable  function  (see  RM  3.4(11))). 

Caution:  CONVERT  cannot  be  instantiated  directly  with  the 
names  VSTR  and  STR,  since  the  name  of  the  subprogram  being 
declared  would  hide  the  generic  parameters  with  the  same 
names  (see  RM  8.3(16)).  CONVERT  can  be  instantiated  with 
the  operator  and  any  instantiation  of  CONVERT  can 
subsequently  be  renamed  VSTR  or  STR. 

Example:  Given  two  VSTRINGS  instantiations  X  and  Y: 
function  is  new  X.CONVERT(X. VSTRING,  Y. VSTRING); 
function  "+"  is  new  X.CONVERT(Y. VSTRING,  X. VSTRING); 

(Y. CONVERT  could  have  been  used  in  place  of  X. CONVERT) 

function  VSTR(A  :  X. VSTRING)  return  Y. VSTRING  renames  "+"; 
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function  VSTR(A  :  Y. VSTRING)  return  X. VSTRING  renames 


is  equivelent  to  VSTR.  It  is  supplied  as  a  short-hand 
notation  for  the  function.  The  operator  cannot  immed¬ 
iately  follow  the  operator;  use  ...  &  (♦  ...)  instead. 

DISCUSSION: 

This  package  implements  the  type  “variable- length  string"  (vstring) 
using  generics.  The  alternative  approaches  are  to  use  a  discriminant 
record  in  which  the  discriminant  controls  the  length  of  a  STRING  inside 
the  record,  or  a  record  containing  an  access  type  which  points  to  a 
string,  which  can  be  deallocated  and  reallocated  when  necessary. 

Advantages  of  this  package: 

*  The  other  approaches  force  the  vstring  to  be  a  limited  private 
type.  Thus,  their  vstrings  cannot  appear  on  the  left  side  of 
the  assignment  operator;  ie.,  their  vstrings  cannot  be  given 
initial  values  or  values  by  direct  assignment.  This  package 
uses  a  private  type;  therefore,  these  things  can  be  done. 

*  The  other  approach  stores  the  vstring  in  a  string  whose  length 
is  determined  dynamically.  This  package  uses  a  fixed  length 
string.  This  difference  might  be  reflected  in  faster  and  more 
consistent  execution  times  (this  has  NOT  been  verified). 

Disadvantages  of  this  package: 

*  Different  instantiations  must  be  used  to  declare  vstrings  with 
different  maximum  lengths  (this  may  be  desirable,  since 
CONSTRAINT_ERROR  will  be  raised  if  the  maximum  is  exceeded). 

*  A  second  declaration  is  required  to  give  the  type  declared  by 
the  instantiation  a  name  other  than  "VSTRING." 

*  The  storage  required  for  a  vstring  is  determined  by  the  generic 
parameter  LAST  and  not  the  ?ctual  length  of  its  contents.  Thus, 
each  object  is  allocated  the  maximum  amount  of  storage,  regardless 
of  its  actual  size. 

MISCELLANEOUS: 

Constraint  checking  is  done  explicitly  in  the  code;  thus,  it  cannot 
be  suppressed.  On  the  other  hand,  constraint  checking  is  not  lost 
if  pragma  suppress  is  supplied  to  the  compilation  (-S  option) 

(The  robustness  of  the  explicit  constraint  checking  has  NOT  been 
determined). 

Compiling  with  the  optimizer  (-0  option)  may  significantly  reduce 
the  size  (and  possibly  execution  time)  of  the  resulting  executable. 

Compiling  an  instantiation  of  VSTRINGS  is  roughly  equivelent  to 
recompiling  VSTRINGS.  Since  this  takes  a  significant  amount  of  time, 
and  the  instantiation  does  not  depend  on  any  other  library  units, 
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it  is  STRONGLY  recommended  that  the  instantiation  be  compiled 
separately,  and  thus  done  only  ONCE. 

--  USAGE:  with  VSTRINGS; 

package  package_name  is  new  VSTRINGS(maximumJength); 


with  TEXT  JO;  use  TEXT  JO; 
generic 

LAST  :  NATURAL ; 
package  VSTRINGS  is 

subtype  STR1N0EX  is  NATURAL ; 

FIRST  :  constant  STR INDEX  :=  STR INDEX 'FIRST  ♦  1; 
type  VSTRING  is  private; 

NUL  :  constant  VSTRING; 

--  Attributes  of  a  VSTRING 

function  LENCFROM  :  VSTRING)  return  STRINDEX; 
function  HAX(FROM  :  VSTRING)  return  STRINOEX; 
function  STR(FROM  :  VSTRING)  return  STRING; 
function  CHARCFROM:  VSTRING;  POSITION  :  STRINDEX  :  =  FIRST) 
return  CHARACTER; 


--  Comparisons 

function  "<"  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN; 
function  ">"  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN; 
function  •'<="  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN; 
function  ">='•  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN; 
function  equal  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN; 
function  notequal  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN; 


--  Input/Output 

procedure  PUT(FILE  :  in  FILE JYPE;  ITEM  :  in  VSTRING); 
procedure  PUTOTEM  :  in  VSTRING); 

procedure  PUTJINE(FILE  :  in  FILE  JYPE;  ITEM  :  in  VSTRING); 
procedure  PUT JINE( ITEM  :  in  VSTRING); 

procedure  GET(FILE  :  in  FILE  JYPE;  ITEM  :  out  VSTRING; 

LENGTH  :  in  STRINDEX  :=  LAST): 

procedure  GET ( I TEM  :  out  VSTRING;  LENGTH  :  in  STRINDEX  :=  LAST); 

procedure  GET  JINE(F!LE  :  in  FILE  JYPE;  ITEM  :  in  out  VSTRING); 
procedure  GET JINE( ITEM  :  in  out  VSTRING); 

--  Extraction 
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function  SLICE(FROM:  VSTRING;  FRONT,  BACK  :  STRINDEX)  return  VSTRING; 
function  SUBSTR(FROM:  VSTRING;  START,  LENGTH:  STRINDEX)  return  VSTRING; 
function  DELETE (FROM:  VSTRING;  FRONT,  BACK  :  STRINDEX)  return  VSTRING; 

Editing 

function  INSERT(TARGET:  VSTRING;  ITEM:  VSTRING; 

POSITION:  STRINDEX  :  =  FIRST)  return  VSTRING; 
function  INSERT (TARGET:  VSTRING;  ITEM:  STRING; 

POSITION:  STRINDEX  :=  FIRST)  return  VSTRING; 
function  INSERT(TARGET:  VSTRING;  ITEM:  CHARACTER; 

POSITION:  STRINDEX  :=  FIRST)  return  VSTRING; 

function  APPEND(TARGET :  VSTRING;  ITEM:  VSTRING;  POSITION:  STRINDEX) 
return  VSTRING; 

function  APPEND(TARGET:  VSTRING;  ITEM:  STRING;  POSITION:  STRINDEX) 
return  VSTRING; 

function  APPEND(TARGET :  VSTRING;  ITEM:  CHARACTER;  POSITION:  STRINDEX) 
return  VSTRING; 

function  APPEND(TARGET:  VSTRING;  ITEM:  VSTRING)  return  VSTRING; 
function  APPEND(TARGET:  VSTRING;  ITEM:  STRING)  return  VSTRING; 
function  APPEND(TARGET :  VSTRING;  ITEM:  CHARACTER)  return  VSTRING; 

function  REPLACE(TARGET:  VSTRING;  ITEM:  VSTRING; 

POSITION:  STRINDEX  :=  FIRST)  return  VSTRING; 
function  REPLACE (TARGET :  VSTRING;  ITEM:  STRING; 

POSITION:  STRINDEX  :=  FIRST)  return  VSTRING; 
function  REPLACE (TARGET:  VSTRING;  ITEM:  CHARACTER; 

POSITION:  STRINDEX  :=  FIRST)  return  VSTRING; 


-  Concatenation 

function  (LEFT:  VSTRING;  RIGHT  :  VSTRING)  return  VSTRING; 

function  "S"  (LEFT:  VSTRING;  RIGHT  :  STRING)  return  VSTRING; 

function  (LEFT:  VSTRING;  RIGHT  :  CHARACTER)  return  VSTRING; 

function  (LEFT:  STRING;  RIGHT  :  VSTRING)  return  VSTRING; 

function  (LEFT:  CHARACTER;  RIGHT  :  VSTRING)  return  VSTRING; 

-  Determine  the  position  of  a  substring 

function  INOEX(WHOLE:  VSTRING;  PART:  VSTRING;  OCCURRENCE  :  NATURAL  :=  1) 
return  STRINDEX; 

function  INDEX(UHOLE  :  VSTRING;  PART  :  STRING;  OCCURRENCE  :  NATURAL  :=  1) 
return  STRINDEX; 

function  INDEX(WHOLE  :  VSTRING;  PART  :  CHARACTER;  OCCURRENCE  :  NATURAL  :=  1) 
return  STRINDEX; 


function  RINDEX(UHOLE:  VSTRING;  PART:  VSTRING;  OCCURRENCE  :  NATURAL  :=  1) 
return  STRINDEX; 
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function  R1NDEX(UH0LE  :  VSTRING;  PART  :  STRING;  OCCURRENCE  :  NATURAL  :■  1> 
return  STRINDEX; 

function  RINDEX(WHOLE  :  VSTRING;  PART  :  CHARACTER;  OCCURRENCE  :  NATURAL  :*  1 
return  STRINDEX; 

--  Conversion  from  other  associated  types 

function  VSTR(FROM  :  STRING)  return  VSTRING; 
function  VSTR(FROM  :  CHARACTER)  return  VSTRING; 
function  (FROM  :  STRING)  return  VSTRING; 
function  "♦«  (FROM  :  CHARACTER)  return  VSTRING; 

generic 

type  FROM  is  private; 
type  TO  is  private; 

with  function  STR(X  :  FROM)  return  STRING  is  <>; 
with  function  VSTR(Y  :  STRING)  return  TO  is  <>; 
function  CONVERT(X  :  FROM)  return  TO; 

private 

type  VSTRING  is 
record 

LEN  :  STRINDEX  :  =  STRINDEX' FIRST; 

VALUE  :  STRINGCFIRST  ..  LAST)  :  =  (others  =>  ASCII.NUL); 
end  record; 

NUL  :  constant  VSTRING  :=  (STRINDEX'FIRST,  (others  =>  ASCII.NUL)); 
end  VSTRINGS; 


-  DISTRIBUTION  AND  COPYRIGHT: 

-  This  software  is  released  to  the  Public  Domain  (note: 

software  released  to  the  Public  Domain  is  not  subject 
to  copyright  protection). 

-  Restrictions  on  use  or  distribution:  NONE 

-  DISCLAIMER: 

-  This  software  and  its  documentation  are  provided  "AS  IS"  and 

-  without  any  expressed  or  implied  warranties  whatsoever. 

-  No  warranties  as  to  performance,  merchantability,  or  fitness 

-  for  a  particular  purpose  exist. 

-  Because  of  the  diversity  of  conditions  and  hardware  under 

-  which  this  software  may  be  used,  no  warranty  of  fitness  for 

-  a  particular  purpose  is  offered.  The  user  is  advised  to 

-  test  the  software  thoroughly  before  relying  on  it.  The  user 

-  must  assume  the  entire  risk  and  liability  of  using  this 

-  software. 
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In  no  event  shall  any  person  or  organization  of  people  be 
held  responsible  for  any  direct,  indirect,  consequential 
or  inconsequential  damages  or  lost  profits. 


UNIT:  generic  package  body  of  VSTRINGS 

FILES:  vstring_body.a  in  publiclib 

related  file  is  vstring_spec.a  in  publiclib 

PURPOSE:  An  implementation  of  the  abstract  data  type  “variable- length 
string." 

DESCRIPTION:  This  package  provides  a  private  type  VSTRING.  VSTRING  objects 
are  "strings"  that  have  a  length  between  zero  and  LAST,  where 
LAST  is  the  generic  parameter  supplied  in  the  package 
instantiation. 

In  addition  to  the  type  VSTRING,  a  subtype  and  two  constants 
are  declared.  The  subtype  STRINDEX  is  an  index  to  a  VSTRING, 
The  STRINDEX  constant  FIRST  is  an  index  to  the  first  character 
of  the  string,  and  the  VSTRING  constant  NUL  is  a  VSTRING  of 
length  zero.  NUL  is  the  default  initial  value  of  a  VSTRING. 

The  following  sets  of  functions,  procedures,  and  operators 
are  provided  as  operations  on  the  type  VSTRING: 

ATTRIBUTE  FUNCTIONS:  LEN,  MAX,  STR,  CHAR 

The  attribute  functions  return  the  characteristics  of 
a  VSTRING. 

COMPARISON  OPERATORS:  "=",  "<",  ">",  »<=»,  »>=" 

The  comparison  operators  are  the  same  as  for  the  predefined 
type  STRING. 

INPUT/OUTPUT  PROCEDURES:  GET,  GET_LINE,  PUT,  PUTJ.INE 

The  input/output  procedures  are  similar  to  those  for  the 
predefined  type  STRING,  with  the  following  exceptions: 

-  GET  has  an  optional  parameter  LENGTH,  which  indicates 
the  number  of  characters  to  get  (default  is  LAST). 

-  GET_LINE  does  not  have  a  parameter  to  return  the  length 
of  the  string  (the  LEN  function  should  be  used  instead). 

EXTRACTION  FUNCTIONS:  SLICE,  SUBSTR,  DELETE 
The  SLICE  function  returns  the  slice  of  a  VSTRING  between 
two  indices  (equivalent  to  STR(X)(A  ..  B)). 
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SUBSTR  returns  a  substring  of  a  VSTRING  taken  from  a  given 
index  and  extending  a  given  length. 

The  DELETE  function  returns  the  VSTRING  which  results  from 
removing  the  slice  between  two  indices. 

EDITING  FUNCTIONS:  INSERT,  APPEND,  REPLACE 
The  editing  functions  return  the  VSTRING  which  results  from 
inserting,  appending,  or  replacing  8t  a  given  index  with  a 
VSTRING,  STRING,  or  CHARACTER.  The  index  must  be  in  the 
current  range  of  the  VSTRING;  i.e.,  zero  cannot  be  used. 

CONCATENATION  OPERATOR: 

The  concatenation  operator  is  the  same  as  for  the  type 
STRING.  It  should  be  used  instead  of  APPEND  when  the 
APPEND  would  always  be  after  the  last  character. 

POSITION  FUNCTIONS:  INDEX,  R INDEX 
The  position  functions  return  an  index  to  the  Nth  occurrence 
of  a  VSTRING,  STRING,  or  CHARACTER  from  the  front  or  back 
of  a  VSTRING.  2ero  is  returned  if  the  search  is  not 
successful. 

CONVERSION  FUNCTIONS  AND  OPERATOR:  VSTR,  CONVERT,  •*+" 

VSTR  converts  a  STRING  or  a  CHARACTER  to  a  VSTRING. 

CONVERT  is  a  generic  function  which  can  be  instantiated  to 
convert  from  any  given  variable- length  string  to  another, 
provided  the  FROM  type  has  a  function  equivelent  to  STR 
defined  for  it,  and  that  the  TO  type  has  a  function  equiv¬ 
elent  to  VSTR  defined  for  it.  This  provides  a  means  for 
converting  between  VSTRINGs  declared  in  separate  instant¬ 
iations  of  VSTRINGS.  When  instantiating  CONVERT  for 
VSTRINGs,  the  STR  and  VSTR  functions  are  implicitly  defined, 
provided  that  they  have  been  made  visible  (by  a  use  clause). 

Note:  CONVERT  is  NOT  implicitly  associated  with  the  type 
VSTRING  declared  in  this  package  (since  it  would  not  be  a 
derivable  function  (see  RM  3.4(11))). 

Caution:  CONVERT  cannc,'  be  instantiated  directly  with  the 
names  VSTR  and  STR,  since  the  name  of  the  subprogram  being 
declared  would  hide  the  generic  parameters  with  the  same 
tames  (see  RM  8.3(16)).  CONVERT  can  be  instantiated  with 
the  operator  and  any  instantiation  of  CONVERT  can 

subsequently  be  renamed  VSTR  or  STR. 

Example:  Given  two  VSTRINGS  instantiations  X  and  Y: 
function  "+«  is  new  X. CONVERTS. VSTRING,  Y. VSTRING); 
function  is  new  X.CONVERT(Y. VSTRING,  X. VSTRING); 
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(Y. CONVERT  could  have  been  used  in  place  of  X. CONVERT) 

function  VSTR(A  :  X.VSTRING)  return  Y.VSTRING  renames 
function  VSTR(A  :  Y.VSTRING)  return  X.VSTRING  renames  "♦"; 

is  equivelent  to  VSTR.  It  is  supplied  as  a  short-hand 
notation  for  the  function.  The  "+"  operator  cannot  immed¬ 
iately  follow  the  "&"  operator;  use  ...  &  (+  ...)  instead. 

DISCUSSION: 

This  package  implements  the  type  "variable- length  string"  (vstring) 
using  generics.  The  alternative  approaches  are  to  use  a  discriminant 
record  in  which  the  discriminant  controls  the  length  of  a  STRING  inside 
the  record,  or  a  record  containing  an  access  type  which  points  to  a 
string,  which  can  be  deallocated  and  reallocated  when  necessary. 

Advantages  of  this  package: 

*  The  other  approaches  force  the  vstring  to  be  a  limited  private 
type.  Thus,  their  vstrings  cannot  appear  on  the  left  side  of 
the  assignment  operator;  ie.,  their  vstrings  cannot  be  given 
initial  values  or  values  by  direct  assignment.  This  package 
uses  a  private  type;  therefore,  these  things  can  be  done. 

*  The  other  approach  stores  the  vstring  in  a  string  whose  length 
is  determined  dynamically.  This  package  uses  a  fixed  length 
string.  This  difference  might  be  reflected  in  faster  and  more 
consistent  execution  times  (this  has  NOT  been  verified). 

Disadvantages  of  this  package: 

*  Different  instantiations  must  be  used  to  declare  vstrings  with 
different  maximum  lengths  (this  may  be  desirable,  since 
CONSTRA 1 NT_ERROR  will  be  raised  if  the  maximum  is  exceeded). 

*  A  second  declaration  is  required  to  give  the  type  declared  by 
the  instantiation  a  name  other  than  "VSTRING." 

*  The  storage  required  for  a  vstring  is  determined  by  the  generic 
parameter  LAST  and  not  the  actual  length  of  its  contents.  Thus, 
each  object  is  allocated  the  maximum  amount  of  storage,  regardless 
of  its  actual  size. 

MISCELLANEOUS: 

Constraint  checking  is  done  explicitly  in  the  code;  thus,  it  cannot 
be  suppressed.  On  the  other  hand,  constraint  cheeking  is  not  lost 
if  pragma  suppress  is  supplied  to  the  compilation  (-S  option) 

(The  robustness  of  the  explicit  constraint  checking  has  NOT  been 
determined). 

Compiling  with  the  optimizer  (-0  option)  may  significantly  reduce 
the  size  (and  possibly  execution  time)  of  the  resulting  executable. 
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Compiling  an  instantiation  of  VSTRINGS  is  roughly  equivalent  to 
recompiling  VSTRINGS.  Since  this  takes  a  significant  amount  of  time, 
and  the  instantiation  does  not  depend  on  any  other  library  units, 
it  is  STRONGLY. recommended  that  the  instantiation  be  compiled 
separately,  and  thus  done  only  ONCE. 

-  USAGE:  with  VSTRINGS; 

package  package_name  is  new  VSTRINGS(maximum_length); 


package  body  VSTRINGS  is 
--  local  declarations 

FILL_CHAR  :  constant  CHARACTER  :=  ASCII.NUL; 

procedure  FORMAT (THE_STR I NG  :  in  out  VSTRING;  OLDLEN  :  in  STRINDEX  :=  LAST)  is 
--  fill  the  string  with  FILL_CHAR  to  null  out  old  values 

begin  --  FORMAT  (Local  Procedure) 

THE_STRING.VALUE(THE_STRING.LEN  ♦  1  ..  OLDLEN)  := 

(others  =>  FILL_CHAR); 

end  FORMAT; 


--  bodies  of  visible  operations 

function  LEN(FR0M  :  VSTRING)  return  STRINDEX  is 

begin  -*  LEN 

return( FROM . LEN ) ; 
end  LEN; 


function  MAX (FROM  :  VSTRING)  return  STRINDEX  is 
begin  --  MAX 
return(LAST); 
end  MAX; 


function  STR(FROM  :  VSTRING)  return  STRING  is 
begin  --  STR 

return( FROM. VALUE ( FIRST  ..  FROM. LEN)); 
end  STR; 


function  CHAR(FR0M  :  VSTRING;  POSITION  :  STRINDEX  :=  FIRST) 
return  CHARACTER  is 

begin  --  CHAR 

if  POSITION  not  in  FIRST  ..  FROM. LEN 
then  raise  CONSTRAINT_ERROR; 
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end  if; 

return( FROM . VALUE (POS I T I ON ) ) ; 
end  CHAR; 


function  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN  is 
begin  --  "<“ 

retum(LEFT. VALUE  <  RIGHT. VALUE); 
end  ll<ll  . 


function  ">"  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN  is 
begin  --  ">" 

return( LEFT. VALUE  >  RIGHT. VALUE); 
end  ">"; 


function  "<='*  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN  is 
begin  --  "<=" 

return(LEFT. VALUE  <=  RIGHT. VALUE); 
end  “ea"; 


flection  ,,>=“  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN  is 
begin  --  ">=" 

return(LEFT. VALUE  >=  RIGHT. VALUE); 
end 

function  equal  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN  is 
begin  *•  equal 

return(LEFT. VALUE  =  RIGHT. VALUE); 
end  equal; 

function  notequal  (LEFT:  VSTRING;  RIGHT:  VSTRING)  return  BOOLEAN  is 
begin  --  notequal 

returnUEFT. VALUE  /=  RIGHT. VALUE); 
end  notequal; 


procedure  PUT(FILE  :  in  FILE_TYPE;  ITEM  :  in  VSTRING)  is 
begin  --  PUT 

PUT(FILE,  ITEM.VALUE(FIRST  ..  ITEM.LEN)); 
end  PUT; 

procedure  Put(ITEM  :  in  VSTRING)  is 
begin  --  PUT 

PUT(ITEM.VALUE(FIRST  ..  ITEM.LEN)); 
end  PUT; 


procedure  PUT_LINE(FILE  :  in  FILEJYPE;  ITEM  :  in  VSTRING)  is 
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begin  --  PUT_LINE 

PUT_LINE(FILE,  !TEM.VALUE(FIRST  ..  ITEM.LEN)); 
end  PUT_LINE; 


procedure  PUT_LINE( ITEM  :  in  VSTRING)  is 
begin  --  PUTJ.INE 

PUT_L I NE ( I TEM . VALUEL  F I RST  ..  ITEM.LEN)); 
end  PUT_LINE; 


procedure  GET(FILE  :  in  FILE_TYPE;  ITEM  :  out  VSTRING; 
LENGTH  ;  in  STR INDEX  :=  LAST)  is 

begin  --  GET 

if  LENGTH  not  in  FIRST  ..  LAST 
then  raise  CONSTR A I NT_ERR0R ; 
end  if; 


ITEM  :=  NUL; 

for  INDEX  in  FIRST  ..  LENGTH  loop 
GETCFILE,  ITEM. VALUE (INDEX)); 
ITEM.LEN  :=  INDEX; 
end  loop; 
end  GET; 


procedure  GETOTEM  :  out  VSTRING;  LENGTH  :  in  STRINDEX  :=  LAST)  is 
begin  -•  GET 

if  LENGTH  not  in  FIRST  ..  LAST 
then  raise  CONSTRAINT_ERROR; 
end  if; 

ITEM  :=  NUL; 

for  INDEX  in  FIRST  ..  LENGTH  loop 
GET ( ITEM. VALUEC INDEX) ); 

ITEM.LEN  :=  INDEX; 
end  loop; 
end  GET; 


procedure  GET_LINE(FILE  :  in  FILE_TYPE;  ITEM  :  in  out  VSTRING)  is 
OLDLEN  :  constant  STRINDEX  :=  ITEM.LEN; 
begin  --  GETJ.INE 

GET_LINE(FILE,  ITEM. VALUE,  ITEM.LEN); 

FORMATUTEM,  OLDLEN); 
end  GET_LINE; 

procedure  GET_LINE( ITEM  :  in  out  VSTRING)  is 
OLDLEN  :  constant  STRINDEX  :=  ITEM.LEN; 
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begin  --  GET_LINE 
GET_LINE(1TEM. VALUE,  ITEM.LEN); 
FORMAT < ITEM,  OLOLEN); 
end  GET_LINE; 


function  SUC£(FROM  :  VSTRING;  FRONT,  BACK  :  STRINDEX)  return  VSTRING  is 


begin  --  SLICE 

if  ((FRONT  not  in  FIRST  ..  FROM.LEN)  or  else 

(BACK  not  in  FIRST  ..  FROM.LEN))  and  then  FRONT  <=  BACK 
then  raise  CONSTRAINT_ERROR; 
end  if; 

return(Vstr( FROM. VALUE( FRONT  ..  BACK))); 
end  SLICE; 


function  SU8STR(FROM  :  VSTRING;  START,  LENGTH  :  STRINDEX)  retur  ,  VSiRING  is 
begin  --  SUBSTR 

if  (START  not  in  FIRST  ..  FROM.LEN)  or  else 

((START  +  LENGTH  -  1  not  in  FIRST  ..  FROM.LEN) 
and  then  (LENGTH  >  0)) 
then  raise  CONSTRA I NT_ERROR ; 
end  if; 

return( Vstr( FROM. VALUE (START  ..  START  +  LENGTH  *1))); 
end  SUBSTR; 


function  DELETE(FROM  :  VSTRING;  FRONT,  BACK  :  STRINDEX)  return  VSTRING  is 
TEMP  :  VSTRING  :=  FROM; 
begin  --  DELETE 

if  ( ( r~/'"T  not  jn  fIRST  __  FROM.LEN)  or  else 

(B*  ;Ot  in  FIRST  ..  FROM.LEN))  and  then  FRONT  <=  BACK 
then  raise  CONSTRA I NT_ERROR; 
end  if; 

if  FRONT  >  BACK  then  return(FROM);  end  if; 

TEMP.LEN  :=  FROM.LEN  -  (BACK  •  FRONT)  -  1; 

TEMP. VALUE (FRONT  ..  TEMP.LEN)  :=  FROM. VALUE (BACK  +  1  ..  FROM.LEN); 
FORMAT (TEMP,  FROM.LEN); 
return(TEMP); 
end  DELETE; 


function  INSERT(TARG£T :  VSTRING;  ITEM:  VSTRING; 
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POSITION  :  STRINDEX  :=  FIRLf)  return  VSTRING  is 


TEMP  :  VSTRING; 
begin  --  INSERT 

if  POSITION  not  in  FIRST  ..  TARGET. LEN 
then  ra.se  CONSTRA I NT_ERROR ; 
end  if; 

if  TARGET. LEN  +  ITEM. LEN  >  LAST 
then  raise  CONSTRA I NT_ERROR; 
else  TEMP. LEN  :=  TARGET. LEN  +  ITEM. LEN; 
end  if; 

TEMP.VALUECFIRST  ..  POSITION  -  1)  :=  TARGET. VALUEfFIRST  ..  POSITION  -  1) 

TEMP . VALUE ( POS I T I ON  ..  (POSITION  +  ITEM. LEN  -  1>>  := 

1TEM.VALUE( FIRST  ..  ITEM. LEN); 

TEMP. VALUE (( POS I T I ON  +  ITEM. LEN)  ..  TEMP. LEN)  := 

TARGET. VALUE (POS IT  ION  ..  TARGET. LEN); 

return(TEMP); 
end  INSERT; 

function  INSERT(TARGET :  VSTRING;  ITEM:  STRING; 

POSITION  :  STRINDEX  :=  FIRST)  return  VSTRING  is 
begin  --  INSERT 

return  INSERT(TARGET,  VSTR(ITEM),  POSITION); 
end  INSERT; 

function  INSERT(TARGET:  VSTRING;  ITEM:  CHARACTER; 

POSITION  :  STRINDEX  :=  FIRST)  return  VSTRING  is 
begin  --  INSERT 

return  INSERT(TARGET,  VSTR( ITEM),  POSITION); 
end  INSERT; 


function  APPEND(TARGET :  VSTRING;  ITEM;  VSTRING;  POSITION  :  STRINDEX) 
return  VSTRING  is 

TEMP  :  VSTRING; 

POS  :  STRINDEX  :=  POSITION; 

begin  --  APPEND 

if  POSITION  not  in  FIRST  ..  TARGET. LEN 
then  raise  CONSTRA I NT_ERROR; 
end  if; 

if  TARGET. LEN  +  ITEM. LEN  >  LAST 
then  raise  CONSTRA I NT_ERROR; 
else  TEMP. LEN  :=  TARGET. LEN  +  ITEM. LEN; 
end  if; 
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TEMP . VALUEC FIRST  ..  POS)  :=  TARGET. VALUE(FIRST  ..  POS); 

TEMP. VALUE (POS  +  1  ..  (POS  +  ITEM.LEN))  :=  ITEM. VALUE(F1RST  ..  ITEM.LEN) 

TEMP. VALUE ((POS  +  ITEM.LEN  +  1)  ..  TEMP.LEN)  := 

TARGET. VALUE (POS  +  1  ..  TARGET.LEN); 

return! TEMP); 
end  APPEND; 

function  APPEND (TARGET:  VSTRING;  ITEM:  STRING;  POSITION  :  STRINDEX) 
return  VSTRING  is 
begin  --  APPEND 

return  APPEND(TARGET,  VSTR(ITEM),  POSITION); 
end  APPEND; 

function  APPEND(TARGET :  VSTRING;  ITEM:  CHARACTER;  POSITION  :  STRINDEX) 
return  VSTRING  is 
begin  --  APPEND 

return  APPEND(TARGET,  VSTR( ITEM),  POSITION); 
end  APPEND; 


function  APPEND(TARGET :  VSTRING;  ITEM:  VSTRING)  return  VSTRING  is 
begin  --  APPEND 

return( APPEND (TARGET,  ITEM,  TARGET.LEN)); 
end  APPEND; 

function  APPEND (TARGET:  VSTRING;  ITEM;  STRING)  return  VSTRING  is 
begin  -•  APPEND 

return( APPEND (TARGET ,  VSTR( ITEM),  TARGET.LEN)); 
end  APPEND; 

function  APPEND(TARGET :  VSTRING;  ITEM:  CHARACTER)  return  VSTRING  is 
begin  --  APPEND 

return( APPEND (TARGET,  VSTR( ITEM),  TARGET.LEN)); 
end  APPEND; 


function  REPLACE(TARGET :  VSTRING;  ITEM:  VSTRING; 

POSITION  :  STRINDEX  :=  FIRST)  return  VSTRING  is 


TEMP  :  VSTRING; 
begin  --  REPLACE 

if  POSITION  not  in  FIRST  ..  TARGET.LEN 
then  raise  CONSTRA I NT_ERROR ; 
end  if; 

if  POSITION  +  ITEM.LEN  -  1  <=  TARGET.LEN 
then  TEMP.LEN  :=  TARGET.LEN; 
elsif  POSITION  +  ITEM.LEN  -  1  >  LAST 
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then  raise  CONSTRA I NT_ERROR ; 
else  TEMP.LEN  :=  POSITION  +  ITEM.LEN  -  1; 
end  if; 

TEMP.VALUEfFIRST  ..  POSITION  -  1)  :=  TAR GET. VALUE{ FIRST  ..  POSITION  -  1); 

TEMP . VALUE < POS I T I ON  ..  (POSITION  +  ITEM.LEN  -  1>>  :  = 

ITEM.VALUECFIRST  ..  ITEM.LEN); 

TEMP . VALUE ( ( POS I T I ON  +  ITEM.LEN)  ..  TEMP.LEN)  :  = 

TARGET. VALUE ((POS IT  ION  +  ITEM.LEN)  ..  TARGET. LEN); 

return(TEMP); 
end  REPLACE; 

function  REPLACE(TARGET :  VSTR1NG;  ITEM:  STRING; 

POSITION  :  STRINOEX  :=  FIRST)  return  VSTRING  is 
begin  --  REPLACE 

return  REPLACEUARGET,  VSTR(ITEM),  POSITION); 
end  REPLACE; 

function  REPLACE(TARGET :  VSTRING;  ITEM:  CHARACTER; 

POSITION  :  STRINOEX  :=  FIRST)  return  VSTRING  is 
begin  --  REPLACE 

return  REPLACE(TARGET,  VSTR(ITEM),  POSITION); 
end  REPLACE; 


function  "&"(  LEFT -.VSTRING;  RIGHT  :  VSTRING)  return  VSTRING  is 
TEMP  :  VSTRING; 


begin  --  "S" 

if  LEFT. LEN  +  RIGHT. LEN  >  LAST 
then  raise  CONSTRA I NT_ERROR; 
else  TEMP.LEN  :=  LEFT. LEN  +  RIGHT. LEN; 
end  if; 

TEMP.VALUE(FIRST  ..  TEMP.LEN)  :=  LEFT.VALUE(FIRST  ..  LEFT. LEN)  & 
RIGHT. VALUE(FIRST  ..  RIGHT. LEN); 

return(TEMP); 
end  "8"; 

function  "&"(LEFT :VSTRING;  RIGHT  :  STRING)  return  VSTRING  is 
begin  --  "8" 

return  LEFT  8  VSTR(RIGHT); 
end  "8"; 

function  "8"(LEFT :VSTRING;  RIGHT  :  CHARACTER)  return  VSTRING  is 
begin  --  "8" 

return  LEFT  8  VSTR(RIGHT); 
end  "8"; 
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function  ll&ll(LEFT  :  STRING;  RIGHT  :  VSTRING)  return  VSTRING  is 
begin  --  "S" 

return  VSTR(LEFT)  &  RIGHT; 
end 

function  '^“(LEFT  :  CHARACTER;  RIGHT  :  VSTRING)  return  VSTRING  is 
begin  --  "S" 

return  VSTR(LEFT)  &  RIGHT; 
end 


Function  INOEX(UHOLE  :  VSTRING;  PART  :  VSTRING;  OCCURRENCE  :  NATURAL  :=  1) 
return  STR INDEX  is 

NOT_FOUND  :  constant  NATURAL  :=  0; 

INDEX  :  NATURAL  :  =  FIRST; 

COUNT  :  NATURAL  :=  0; 

begin  --  INDEX 

if  PART  =  NUL  then  return(NOT_FOUND);  --  by  definition 
end  if; 

while  INDEX  ♦  PART.LEN  -  1  <=  WHOLE. LEN  and  then  COUNT  <  OCCURRENCE  loop 
if  WHOLE. VALUEC INDEX  ..  PART.LEN  ♦  INDEX  -  1)  = 

PART. VALUE (1  ..  PART.LEN) 
then  COUNT  :=  COUNT  +  1; 
end  if; 

INDEX  :=  INDEX  +  1; 
end  loop; 


if  COUNT  =  OCCURRENCE 
then  returnl INDEX  -  1); 
else  return(NOT_FOUND); 
end  if; 
end  INDEX; 

Function  INDEX(WHOLE  :  VSTRING;  PART  :  STRING;  OCCURRENCE  :  NATURAL  :=  1) 
return  STR INDEX  is 

begin  --  Index 

returnf Index(WHOLE,  VSTR(PART),  OCCURRENCE)); 
end  INDEX; 


Function  INOEX(WHOLE  :  VSTRING;  PART  :  CHARACTER;  OCCURRENCE  :  NATURAL  :=  1) 
return  STR INDEX  is 


begin  --  Index 

return( IndexlWHOLE,  VSTR(PART),  OCCURRENCE)); 
end  INDEX; 
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function  RINOEX(WHOLE:  VSTRING;  PART : VSTRING;  OCCURRENCE: NATURAL  :*  1) 
return  STR INDEX  is 

NOT_FOUND  :  constant  NATURAL  :=  0; 

INDEX  :  INTEGER  :=  WHOLE. LEN  -  (PART.LEN  -1); 

COUNT  :  NATURAL  :  =  0; 


begin  --  RINDEX 

if  PART  =  NUL  then  return! NOT_FOUND ) ;  --  by  definition 
end  if; 

while  INDEX  >=  FIRST  and  then  COUNT  <  OCCURRENCE  loop 
if  WHOLE. VALUEdNDEX  ..  PART.LEN  +  INDEX  -  1)  = 

PART. VALUE (1  ..  PART.LEN) 
then  COUNT  :=  COUNT  +  1; 
end  if; 

INDEX  :=  INDEX  -  1; 
end  loop; 

if  COUNT  =  OCCURRENCE 
then 

if  COUNT  >  0 
then  return! INDEX  +  1); 
else  return! NOT_FOUND); 
end  if; 

else  return!NOT_FOUNO); 
end  if; 
end  RINDEX; 

Function  RINDEXIWHOLE  :  VSTRING;  PART  :  STRING;  OCCURRENCE  :  NATURAL  := 
return  STR INDEX  is 

begin  --  R index 

return! R I NDEXIUHOLE ,  VSTR(PART),  OCCURRENCE)); 
end  RINDEX; 


Function  RINDEX!WHOLE  :  VSTRING;  PART  :  CHARACTER;  OCCURRENCE  :  NATURAL 
return  STR INDEX  is 

begin  --  Rindex 

return! RINDEX (WHOLE,  VSTR(PART),  OCCURRENCE)); 
end  RINDEX; 


function  VSTR(FROM  :  CHARACTER)  return  VSTRING  is 
TEMP  :  VSTRING; 


begin  --  VSTR 
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if  LAST  <  1 

then  raise  CONSTRAINT_ERROR; 
else  TEMP.LEN  :=  1; 
end  if; 

TEMP . VALUE (FIRST)  :=  FROM; 
return(TEMP); 
end  VSTR; 


function  VSTR(FROM  :  STRING)  return  VSTR1NG  is 

TEMP  :  VSTRING; 

begin  --  VSTR 

if  FROM 'LENGTH  >  LAST 

then  raise  CONSTRA I NT_ERROR ; 
else  TEMP.LEN  :=  FROM' LENGTH; 
end  if; 

TEMP . VALUE (FIRST  ..  FROM'LENGTH)  :=  FROM; 
return(TEMP); 
end  VSTR; 

Function  "*»  (FROM  :  STRING)  return  VSTRING  is 
begin  --  "+" 

return(VSTR(FROM)); 

end 


Function  (FROM  :  CHARACTER)  return  VSTRING  is 
begin 

return(VSTRCFROM) ); 
end 


function  CONVERT(X  :  FROM)  return  TO  is 

begin  --  CONVERT 

return(VSTR(STR(X))); 
end  CONVERT; 
end  VSTRINGS; 


--  DISTRIBUTION  AND  COPYRIGHT: 

--  This  software  is  released  to  the  Public  Domain  (note: 
software  released  to  the  Public  Domain  is  not  subject 
to  copyright  protection). 

--  Restrictions  on  use  or  distribution:  NONE 

--  DISCLAIMER: 
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This  software  and  its  documentation  are  provided  *'AS  IS"  and 
without  any  expressed  or  implied  warranties  whatsoever. 

No  warranties  as  to  performance,  merchantability,  or  fitness 
for  a  particular  purpose  exist. 

Because  of  the  diversity  of  conditions  and  hardware  under 
which  this  software  may  be  used,  no  warranty  of  fitness  for 
a  particular  purpose  is  offered.  The  user  is  advised  to 
test  the  software  thoroughly  before  relying  on  it.  The  user 
must  assume  the  entire  risk  and  liability  of  using  this 
software. 

In  no  event  shall  any  person  or  organization  of  people  be 
held  responsible  for  any  direct,  indirect,  consequential 
or  inconsequential  damages  or  tost  profits. 


C.  L i st_S i ng l e_Unbounded_Unmanaged 
generic 

type  Item  is  private; 

package  L i st_S i ng l e_Unbounded_Unmanaged  is 
type  List  is  private; 

Null_list  :  constant  List; 

procedure  Construct  (The_Item  :  in  Item; 

And_The_List  :  in  out  List); 

function  Is_Null  (The_List  :  in  List)  return  Boolean; 

function  Head_Of  (The_List  :  in  List)  return  Item; 

function  Tail_Of  (The_List  :  in  List)  return  List; 

Overflow  :  exception; 

List_Is_Null  :  except  ion; 

private 

type  Node; 

type  List  is  access  Node; 

Nul l_L ist  :  constant  List  :=  null; 
end  List_Single_Unbounded_Unmanaged; 

package  body  List_SingleJJnbounded_Unmanaged  is 

type  Node  is 
record 

The_Item  :  I  tern; 

Next  :  List; 

end  record; 

procedure  Construct  (The_Item  :  in  Item; 

And_The_List  :  in  out  List)  is 

begin 

And_The_List  :=  new  Node‘(The_item  =>  The_Item, 

Next  =>  And_The_List); 

except i on 

when  Storage_Error  => 
raise  Overflow; 
end  Construct; 

function  Is_Null  (The_List  :  in  List)  return  Boolean  is 
begin 

return  (The_List  =  null); 
end  Is_Null; 

function  Head_Of  (The_List  :  in  List)  return  Item  is 
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begin 

return  The_List.The_lteni; 
except i on 

when  Constraint_Error  => 
raise  list_!s_Null; 
end  Head_Of; 

function  Tail_Of  (The_List  :  in  List)  return  List  is 
begin 

return  The_List.Next; 
except i on 

uhen  Constraint_Error  => 
raise  List_Is_Null; 
end  Tai l_Of; 

end  List_Single_Unbounded_Unmanaged; 
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D.  PRIORI TY_DE F I N 1 T I ONS 

with  SYSTEM; 
use  SYSTEM; 

package  PRIORITYJJEFINITIONS  is 
BUFFER_PR10RITY  :  constant  priority  :=  10; 

STAT I C_SCHEDULE_PR I OR I TY  :  constant  priority  :=  8; 
DYNAMIC_SCHEDULE_PR10R1TY  :  constant  priority  :*  1; 
end  PRIORI TY_DE F I N I T IONS; 
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